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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the stage 3 of the control plane of the GPRS Tunnelling Protocol, Version 2 for 
Evolved Packet System interfaces (GTPv2-C). 

In this document, unless otherwise specified, the S2a, S2b, S5 and S8 interfaces refer always to the OTP-based S2a, 
S2b, S5 and S8 interfaces respectively . 

GTPv2-C shall be used across the following EPC signalling interfaces: S2a, S2b, S3, S4, S5, S8, SIO, Sll and S16. 
GTPv2-C shall be used across the Sm and Sn interfaces for MBMS in EPS. 

GTPv2-C based protocols shall also be used across Sv (3GPP TS 29.280 [15]) and SlOl (3GPP TS 29.276 [14]) 
interfaces. 

The procedures supported between the TWAN and the PGW on the S2a interface, and between the ePDG and the PGW 
on the S2b interface are specified in 3GPP TS 23.402 [45]. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version appUes. In the case of a reference to a 3GPP dociunent (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23 .003 : "Numbering, addressing and identification" . 

[3] 3GPP TS 23.401 : "General Packet Radio Service (GPRS) enhancements for Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN) access". 

[4] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 

across the Gn and Gp interface". 

[5] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[6] IETF RFC 791 (STD 0005): "Internet Protocol", J. Postel. 

[7] IETF RFC 768 (STD 0006): "User Datagram Protocol", J. Postel. 

[8] 3GPP TS 32.251: "Telecommunication Management; Charging Management; Packet Switched 

(PS) domain charging. 

[9] 3GPP TS 32.298: "Telecommunication Management; Charging Management; Charging Data 

Record (CDR) parameter classification. 

[10] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); SI 

Application Protocol (SlAP)". 

[II] 3GPP TS 33.102: "3G security; Security architecture". 

[12] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture". 
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[13] 3GPP TS 29.281 : "General Packet Radio System (GPRS) Tuimelling Protocol User Plane 

(GTPvl-U)". 

[14] 3GPP TS 29.276: "3GPP Evolved Packet System (EPS); Optimized handover procedures and 

protocols between E-UTRAN Access and cdma2000 HRPD Access; Stage 3". 

[15] 3GPP TS 29.280: "Evolved Packet System (EPS); 3GPP Sv interface (MME to MSG, and SGSN 

toMSC)forSRVCC". 

[16] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification". 

[17] 3GPP TS 23.007: "Restoration procedures". 

[18] 3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace; Trace 

control and configuration management ". 

[19] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2". 

[20] 3GPP TS 36.414: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); SI data 

transport". 

[21] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2". 

[22] 3GPP TS 29.118: "MobiUty Management Entity (MME) - Visitor Location Register (VLR) SGs 

interface specification". 

[23] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 

3". 

[24] void 

[25] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[26] 3GPP TS 29.275: "Proxy Mobile IPv6 (PMIPv6) based Mobihty and Tunnelling protocols; Stage 

3". 

[27] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol". 

[28] 3GPP TS 48.008: "Mobile Switching Centre - Base Station System (MSC-BSS) interface; Layer 3 

specification". 

[29] 3GPP TS 29.212: "Policy and Charging Control (PCC); Reference points". 

[30] 3GPP TS 24.007: "Mobile radio interface signalling layer 3; General Aspects". 

[3 1] IETF RFC 1035: "Domain Names - Implementation and Specification". 

[32] 3GPP TS 29.303: "Domain Name System Procedures; Stage 3". 

[33] 3GPP TS 25.413: "UTRAN lu interface Radio Access Network Application Part (RANAP) 

signalhng". 

[34] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN); BSS GPRS protocol (BSSGP)". 

[35] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 
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[36] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data 

Record (CDR) transfer". 

[37] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional 

description". 

[38] 3GPP TS 29.061: "Interworking between the Pubhc Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN) ". 

[39] IETF RFC 3588: "Diameter Base Protocol ". 

[40] IETF RFC 4607: " Source-Specific Multicast for IP" . 

[41] 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

[42] 3GPP TS 29.010: "Information element mapping between Mobile Station - Base Station System 

(MS - BSS) and Base Station System - Mobile-services Switching Centre (BSS - MSC); Signalling 
procedures and the Mobile Application Part (MAP)". 

[43] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2". 

[44] 3GPP TS 32.423: "Telecommunication management; Subscriber and equipment trace: Trace data 

definition and management". 

[45] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses. 

[46] 3GPP TR 25.999: "HSPA Evolution (FDD)". 

[47] 3GPP TS 23 .292: "IP Multimedia Subsystem (IMS) centralized services" . 

[48] 3GPP TS 23.203: "Pohcy and charging control architecture; Stage 2". 

[49] ITU-T Recommendation X.69 1 (07/2002): "Information technology - ASN. 1 encoding rules: 

Specification of Packed Encoding Rules (PER)". 

[50] 3GPP TS 33.402: "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP 

accesses". 

[51] 3GPP TS 23.139: "3GPP system - fixed broadband access network interworking; Stage 2". 

[52] IEEE Std 802. 1 1-2012: "IEEE Standard for Information technology - Telecommunications and 

information exchange between systems - Local and metropolitan area networks - Specific 
requirements - Part 1 1 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) 
Specifications". 

3 Definitions, symbols and abbreviations 
3.1 Definitions 



For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

GTP-PDU: GTP Protocol Data Unit is either a GTP-C Message or a GTP-U Message. GTP-U Message may be either a 
signalling message across the user plane tunnel, or a G-PDU (see clause 6). 

• Signalling Message: any GTP-PDU (GTP-C or GTP-U) except the G-PDU. 

• G-PDU: GTP user plane message, which carries the original packet (payload). G-PDU consists of GTP-U 
header and a T-PDU. 

• T-PDU: original packet, for example an IP datagram, from an UE or a network node in an external packet data 
network. A T-PDU is the payload that is turmelled in the GTP-U turmel. 
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• GTP-C Message: GTP control plane message type of a GTP-PDU. GTP-C message consists of GTP-C 
header, which is followed by zero or more information elements. 

• GTP-U Message: GTP user plane message. The user plane messages are used to carry user data packets, and 
also signalling messages e.g. for path management and error indication. Therefore, GTP-U message consists of 
GTP-U header, which is followed by either a T-PDU, or zero or more information elements. 

GTP Tunnel: A GTP timnel is a communication tunnel between two GTP nodes (see subclause 4.1 "GTP Timnel"). 

Tunnel Endpoint: A tunnel endpoint is identified with a TEID, an IP address and a UDP port number (see subclause 

4.1 "GTP Tunnel"). 

Tunnel Endpoint Identifier (TEID): imambiguously identifies a tunnel endpoint in scope of a path (see subclause 4.1 
"GTP Tunnel"). 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

S 1-U Interface between SGW and eNodeB 

X2 Interface between eNodeB s 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 fll. 



AMBR 


Aggregate Maximum Bit Rate 


APN 


Access Point Name 


APN-NI 


Access Point Name Network Identifier 


APN-OI 


Access Point Name Operator Identifier 


C-MSISDN 


Correlation MSISDN 


EBI 


EPS Bearer ID 


eNodeB 


Evolved Node B 


EPC 


Evolved Packet Core 


ePDG 


Evolved Packet Data Gateway 


EPS 


Evolved Packet System 


F-TEID 


Fully Qualified Tunnel Endpoint Identifier 


G-PDU 


GTP-U non-signalling PDU 


GPRS 


General Packet Radio Service 


GTP 


GPRS Tunnelling Protocol 


GTP-PDU 


GTP-C PDU or GTP-U PDU 


GTPv2-C 


GTP version 2, control plane 


GTPv2-U 


GTP version 2, user plane 


IMSI 


International Mobile Subscriber Identity 


IP 


Internet Protocol 


LBI 


Linked Bearer identity 


LI 


Layer 1 


L2 


Layer 2 


LGW 


Local Gateway 


LIPA 


Local IP Access 


MBMS 


Multimedia Broadcast/Multicast Service 


MEI 


Mobile Equipment Identity 


MSISDN 


Mobile Subscriber ISDN Number 


PAA 


PDN Address Allocation 


PCO 


Protocol Configuration Options 


PDU 


Protocol Data Unit 


PDN 


Packet Data Network or Public Data Network 


PGW 


PDN Gateway 


PTI 


Procedure Transaction Id 


QoS 


QuaUty of Service 
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RAT 


Radio Access Type 


RIM 


RAN Information Management 


SGW 


Serving Gateway 


STN-SR 


Session Transfer Number for SRVCC 


TEID 


Tunnel Endpoint Identifier 


TEID-C 


Tunnel Endpoint Identifier, control plane 


TEID-U 


Timnel Endpoint Identifier, user plane 


TFT 


Traffic Flow Template 


TLIV 


Type Length Instance Value 


TWAN 


Trusted WLAN Access Network 


UDP 


User Datagram Protocol 


ULI 


User Location Information 
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4 



General 



4.1 



GTP Tunnel 



GTP tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different 
communication flows. 

A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The receiving end side of a 
GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between 
tunnel endpoints using GTP-C or Sl-MME or lu-PS messages. The GTPv2 entity communicates to the peer GTPv2 
entity the TEID value at which it expects to receive all subsequent control plane messages related to that GTP turmel via 



- "Sender F-TEID for Control Plane" IE, 

- "PGW S5/S8/S2a/S2b F-TEID for PMIP based interface or for GTP based Control Plane interface" IE, 

- "MSC Server Sv TEID for Control Plane" IE, 

- "S3/S 1 6/S 1 Address and TEID for Control Plane" IE, or 

- "MME/SGSN Sv TEID for Control Plane" IE. 

The criteria defining when the same or different GTP tunnels shall be used between the two nodes differs between the 
control and the user plane, and also between interfaces. 

For the control plane, for each end-point of a GTP-C tunnel: 

- The TEID-C shall be unique per PDN-Connection on GTP based S2a, S2b, S5 and S8 interfaces. The same 
turmel shall be shared for the control messages related to all bearers associated to the PDN-Coimection. A TEID- 
C on the S2ayS2b/S5/S8 interface shall be released after all its associated EPS bearers are deleted. 

There shall be only one pair of TEID-Cs per UE on each of the S3, SIO and the S16 interfaces. The same tunnel 
shall be shared for the control messages related to the same UE operation. A TEID-C on the S3/S10/S16 
interface shall be released after its associated UE context is removed or the UE is detached. For the S3 interface, 
when ISR is active for the UE, during I-RAT handover between the ISR associated nodes, the existing S3 TEID- 
C may be re-used or new S3 TEID-C may be allocated. During this scenario, if the node decides to allocate new 
S3 TEID-C, it shall release its own old S3 TEID-C. 

- There shall be only one pair of TEID-C per UE over the S 1 1 and the S4 interfaces. The same turmel shall be 
shared for the control messages related to the same UE operation. A TEID-C on the S11/S4 interface shall be 
released after all its associated EPS bearers are deleted. 

- There shall be only one pair of TEID-C per MBMS Bearer Service (i.e. per TMGI and, if provided, MBMS Flow 
Identifier) over the Sm and Sn interfaces respectively. The same tuimel shall be shared for the control messages 
related to the same MBMS Bearer Service. A TEID-C on the Sm/Sn interface shall be released after the MBMS 
Bearer Session is stopped. 

For GTP-U, a TEID-U is used according to 3GPP TS 29.281 [13]. 

NOTE: GTP-U is based on GTP version 1 (GTPvl). 



the: 



4.2 



Protocol stack 



4.2.0 



General 



The protocol stack for GTPv2 shall be as depicted in Figure 4.2.0-1. 
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GTP 


1 
1 
1 


GTP 


1 


UDP 


UDP 






IP 


IP 






L2 




L2 






LI 


LI 







GTPv2 entity ; GTPv2 entity 

GTPv2 based 
interface 



Figure 4.2.0-1 : GTPv2 stacl< 



The GTPv2 headers are specified in the respective clauses of this specification. 

The source and destination IP addresses and UDP ports used for each GTP-C message depend on the role that the 
message plays in a message exchange. A message can be an Initial message, or a Triggered message, or a Triggered 
Reply message to Triggered message. An Initial message is sent to a peer GTP entity with a sequence number chosen 
by the sending entity (see subclause 7.6). A Triggered message is sent in response to an Initial message. Triggered 
Reply message may be sent in response to a Triggered message. See subclause 7.6 for the sequence number usage. 

Typically, a Request message is an Initial message, but a Request message may be a Triggered messages in certain 
procedures where they are triggered by an Initial Command message. See subclause 4.2.5 for classification of the Initial 
messages and their possible Triggered messages, as well as cases where there are Triggered Reply messages to the 
Triggered messages. 

Piggybacking is an optional feature. If the feature is supported, then the piggybacking of the initial messages on 
triggered response messages for EUTRAN Initial Attach and UE-requested PDN Connectivity procedures shall be 
implemented as per Annex F of 3GPP TS 23.401 [3]. When piggybacking is used, a common IP header and a common 
UDP header shall be used for the triggered response message and the piggybacked initial message as depicted in Figure 
4.2.0-2. Immediately following the triggered response message is the piggybacked initial message, following which no 
additional information shall be present. The subclause 5.5 specifies the usage of piggybacking-specific fields in the 
GTP-C header. 



IP header 


UDP header 


Triggered response message 


Piggybacked initial message 






(P=1) 


(P=0) 



Figure 4.2.0-2: Packet Format for the Piggybacking of messages 



4.2.1 UDP header and port numbers 
4.2.1.0 General 

A User Datagram Protocol (UDP) compliant with IETF RFC 768 [7] shall be used. 
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4.2.1.1 Initial Messages 

The UDP Destination Port number for GTPv2 Initial messages shall be 2123. It is the registered port number for GTP- 
C. 

The UDP Source Port for a GTPv2 Initial message is a locally allocated port number at the sending OTP entity. 

If GTPv2 and OTP' v2 modules are using the same IP address for sending messages, the implementation shall ensure 
that while some source port number is used by GTPv2 messages, the same source port number shall not be used by 
OTP' v2 messages. Otherwise, the IP interface may have difficulty to delivering a response message to the right 
protocol entity. 

4.2.1.2 Triggered Messages 

The UDP Destination Port value of a GTPv2 Triggered message and for a Triggered Reply message shall be the value 
of the UDP Source Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the 
SGSN pool scenario. 

The UDP Source Port of a GTPv2 Triggered message and for a Triggered Reply message shall be the value from the 
UDP Destination Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the 
SGSN pool scenario. 

In the SGSN pool scenario, if the Identification Request, the Context Request or the Suspend Notification messages 
have been forwarded by another SGSN in the pool, the UDP Destination Port for the Identification Response, the 
Context Response or the Suspend Acknowledge message shall be determined in the following way. The value from the 
information element "UDP Somce Port Number", which was sent in the corresponding forwarded request, shall be 
copied into the UDP Destination Port field. The UDP Source Port for the Identification Response, the Context Response 
or the Suspend Acknowledge message may be a locally allocated port number at the sending GTP entity. 

4.2.1.3 Piggybacked Messages 

A piggybacked initial message is carried as a concatenation after a triggered response message and they share a 
connmon UDP header (see Figure 4.2.0-2). 

The UDP Destination port for the IP packet containing both the triggered response message and the piggybacked initial 
message shall be the same as the port number used for the triggered response message. 

The UDP Source port for the IP packet containing both the triggered response message and the piggybacked initial 
message shall be the same as the port number used for the triggered response message. 

4.2.2 IP header and IP addresses 
4.2.2.1 Initial Messages 

The IP Destination Address of a GTPv2 Initial message shall be an IP address of the destination GTPv2 entity. 

During the establishment of the GTP tunnel, the GTPv2 entity selects and communicates to the peer GTPv2 entity the 
IP Destination Address at which it expects to receive subsequent control plane Initial messages related to that GTP 
tunnel via the: 

- "Sender F-TEID for Control Plane" IE, 

- "PGW S5/S8/S2a/S2b F-TEID for PMIP based interface or for GTP based Control Plane interface" IE, 

- "MSC Sv Address for Control Plane" IE, 

- "S3/S16/S10 Address and TEID for Control Plane" IE, or 

- "MME/SGSN Sv Address for Control Plane" IE. 

During the network triggered service restoration procedure (see 3GPP TS 23.007 [17]), if an MME/S4-SGSN sends a 
DownUnk Data Notification Failure Indication message to the SGW, then the destination address for this message shall 
be the SGW IP address signalled via the Sender F-TEID for Control Plane IE in the Downlink Data Notification 
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message (if present in the message), otherwise the source IP address of the Downhnk Data Notification message 
received eariier. 

The IP Source Address of a GTPv2 Initial message shall be an IP address of the source GTPv2 entity from which the 
Initial message is originating. 

4.2.2.2 Triggered Messages 

The IP Destination Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the 
IP Source Address of the message to which this GTPv2 entity is replying, except in the case of the SGSN pool scenario. 

The IP Source Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the IP 
destination address of the message to which this GTPv2 entity is replying, except in the case of SGSN pool scenario. 

In the SGSN pool scenario, if the Identification Request, the Context Request or the Suspend Notification messages 
have been forwarded by another SGSN in the pool, the IP Source address for the Identification Response, the Context 
Response or the Suspend Acknowledge messages shall be locally allocated by the sending GTP entity. The IP 
Destination Address for the Identification Response, the Context Response or the Suspend Acknowlegde messages shall 
be determined in the following way. The value from the information element "Address for Control Plane", which was 
sent in the corresponding Identification Request or the Suspend Notification message; or the value ftom the information 
element "S3/S16/S10 Address and TEID for Control Plane", which was sent in the corresponding Context Request 
message, shall be copied into the IP Destination Address field. 

4.2.2.3 Piggybacked Messages 

A piggybacked initial message is carried as a concatenation after a triggered response message and they share a 
common IP header (see Figure 4.2.0-2). 

The IP Source Address for the IP packet containing both the triggered response message and the piggybacked initial 
message shall be the same as the IP Address used for the triggered response message. 

The IP Destination Address for the IP packet containing both the triggered response message and the piggybacked 
initial message shall be the same as the IP Address used for the triggered response message. 

4.2.3 Layer 2 

Typically Ethernet should be used as a Layer 2 protocol, but operators may use any other technology. 

4.2.4 Layer 1 

Operators may use any appropriate Layer 1 technology. 

4.2.5 Messages with GTPv2 defined replies: Classification of Initial and 
Triggered Messages 

NOTEl : Other clauses of this specification and Stage 2 documents define in detail when a reply message is 
expected in an end-to-end procedure. Reply messages are triggered messages. 

The expected reply to a Request message is a Triggered message and the reply has the same message name as the 
Request but with "Response" replacing "Request". If a Request message is a reply to a Command message, then the 
Request message is a Triggered message; otherwise the Request message is an Initial message. Responses do not have 
repUes except when a "Context Acknowledge" is required as a reply to "Context Response" message as specified in 
relevant Stage 2 procedures. Context Acknowledge is always triggered message and does not have a reply. 

NOTE2: The "Context Acknowledge" message is sent only if the "Context Response" message is received with the 
acceptance cause. 

A message whose name ends in "Command" is always an initial message. If a "Command" message fails, the name of 
the reply message is constructed by replacing "Command" with "Failure Indication". Apart from "Downlink Data 
Notification Failure Indication" message, a "Failure Indication" is a Triggered message. The "Failure Indication" 
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message does not have a reply. If a "Command" message is successful, its reply will be a Request as specified in 
relevant Stage 2 procedures. 

A message whose name ends in "Notification" is always an Initial message, The expected Triggered message in reply 
has the same message name but with "Acknowledge" replacing "Notification", except for the case of the message 
"Downlink Data Notification" which has the reply "Downlink Data Notification Acknowledge" and "PGW Resart 
Notification" which has the reply "PGW Restart Notification Acknowledge". An "Acknowledge" message does not 
have a reply. 

CS Paging Indication, Stop Paging Indication, RAN Information Relay, Configuration Transfer Turmel, Trace Session 
Activation, Trace Session Deactivation, ISR Status Indication and Downlink Data Notification Failure Indication 
messages are Initial messages that do not have a reply. 

A Version Not Supported Indication message is a Triggered message. 



4.3 Transmission Order and Bit Definitions 

The messages in this document shaU be transmitted in network octet order starting with octet 1 with the Most 

Significant Bit sent first. 

The most significant bit of an octet in a OTP message is bit 8. If a value in a GTP message spans several octets and 
nothing else is stated, the most significant bit is bit 8 of the octet with the lowest number. 



5 GTP Header for Control Plane 



5.1 



General format 



Control Plane GTP uses a variable length header. Control Plane GTP header length shaU be a multiple of 4 octets. 
Figure 5.1-1 illustrates the format of the GTPv2-C Header. 



Octets 
1 
2 
3 
4 
m to 
k(m+3) 
n to (n+2) 
(n+3) 



Bits 

5 4 



Version 



Message Type 



T I Spare | Spare | Spare 



Message Length (r' Octet) 



Message Length (2™ Octet) 



If T flag is set to 1 , then TEID shall be placed into octets 5- 
8. Othenwise, TEID field is not present at all. 



Sequence Number 



Spare 



Figure 5.1-1 : General format of GTPv2 Header for Control Plane 



Where: 



- if T = 0, TEID field is not present, k = 0, m = and n = 5; 

- if T = 1, TEID field is present, k = 1, m = 5 and n = 9. 

The usage of GTPv2-C header across the EPC specific interfaces is defined in the subclause 5.5 "Usage of the GTPv2-C 
Header". Octet 1 bits shall be coded as follows: 



- Bits 6-8 represent the Version field. 

- Bit 5 represents the Piggybacking flag (P). 

- Bit 4 represents the TEID flag (T) . 

- Bits 3-1 are spare, the sender shall set them to "0" and the receiving entity shall ignore them. 
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5.2 Control Plane GTP Extension Header 

The legacy Extension Header mechanism is not used for the GTP version 2 control plane (GTPv2-C). Future extensions 
will be implemented by adding Information Elements in the message body if new parameters are needed. 



5.3 GTP-C header for Echo and Version Not Supported 
messages 

The GTPv2-C message header for the Echo Request, Echo Response and Version Not Supported Indication messages 
shall not contain the TEID field, but shall contain the Sequence Number fields, followed by one spare octet as depicted 
in figure 5.3-1. The spare bits shall be set to zero by the sender and ignored by the receiver. For the Version Not 
Supported Indication message header, the Sequence Number may be set to any number and shall be ignored by the 
receiver. 



Octets 
1 
2 
3 
4 
5 
6 
7 
8 



Bits 



1 



Version 



T=0 I Spare | Spare | Spare 



Message Type 



Message Length (1 Octet) 



Message Length (2^0ctet) 



Sequence Number (1 Octet) 



Sequence Number (2^0ctet) 



Sequence Number (3 Octet) 



Spare 



Figure 5.3-1 : The format of Echo and Version Not Supported messages l-leader 



5.4 EPC specific GTP-C header 



Apart from the Echo Request, Echo Response and Version Not Supported Indication messages, the GTP-C message 
header shall contain the TEID and Sequence Number fields followed by one spare octet. A typical GTP-C header is 
depicted in figure 5.4-1. The spare bits shall be set to zero by the sender and ignored by the receiver. 



Octets 
1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 



Bits 



1 



Version 



T=1 I Spare | Spare | Spare 



Message Type 



Message Length (r' Octet) 



Message Length (2^0ctet) 



Tunnel Endpoint Identifier (1 Octet) 



Tunnel Endpoint Identifier (2™ Octet) 



Tunnel Endpoint Identifier {3'° Octet) 



Tunnel Endpoint Identifier (4 Octet) 



Sequence Number (1 Octet) 



Sequence Number (2"° Octet) 



Sequence Number (3 Octet) 



Spare 



Figure 5.4-1 : The format of EPC specific GTPv2 Control Plane message Header 



5.5 Usage of the GTPv2-C Header 
5.5.1 General 

The format of the GTPv2-C header is specified in subclause 5.1 "General format". The usage of the GTP-C header 
across e.g. SlOl (3GPP TS 29.276 [14]) and Sv (3GPP TS 29.280 [15]) interfaces are defined in their respective 
specifications. 
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The usage of the GTPv2-C header for EPC specific interfaces shall be as defined below. 
The first octet of the header shall be used is the following way: 

Bits 8 to 6, which represent the GTP-C version, shall be set to decimal 2 ("010"). 

Bit 5 represents a "P" flag. If the "P" flag is set to "0", no piggybacked message shall be present. If the "P" flag 
is set to "1", then another GTPv2-C message with its own header and body shall be present at the end of the 
current message. 

When present, a piggybacked message shall have its "P" flag set to "0" in its own header. If a Create Session 
Response message (as part of EUTRAN initial attach or UE-requested PDN connectivity procedure) has the "P" 
flag set to "1", then a Create Bearer Request message shall be present as the piggybacked message. As a 
response to the Create Bearer Request message, if the Create Bearer Response has the "P" flag set to "1", then a 
Modify Bearer Request (as part of EUTRAN initial attach or UE-requested PDN connectivity procedure) shall 
be present as the piggybacked message. A Create Bearer Response with "P" flag set to "1" shall not be sent 
unless a Create Session Response with "P" flag set to " 1 " has been received for the same procedure. Apart from 
Create Session Response and Create Bearer Response messages, all the EPC specific messages shall have the 
"P" flag set to "0". 

Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is 
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID 
field shall inmiediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response 
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be 
set to "1". 

Bit 3 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it. 

- Bit 2 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it. 

- Bit 1 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it. 
The usage of the fields in octets 2 - n of the header shall be as specified below. 

- Octet 2 represents the Message type field, which shall be set to the unique value for each type of control plane 
message. Message type values are specified in Table 6.1-1 "Message types for GTPv2". 

Octets 3 to 4 represent the Message Length field. This field shall indicate the length of the message in octets 
excluding the mandatory part of the GTP-C header (the first 4 octets). The TEID (if present) and the Sequence 
Number shall be included in the length count. The format of the Length field of information elements is specified 
in subclause 8.2 "Information Element Format". 

A piggybacked initial message and the preceding triggered response message present in the common IP/UDP 
packet shall have their own length and sequence number in their respective GTP-C headers. The overall length 
of the IP/UDP packet shall indicate the total length of the two GTP-C messages. 

For EPC specific interfaces, T=l, and therefore octets 5 to 8 represent the Tunnel Endpoint Identifier (TEID) 
field. This field shall unambiguously identify a tunnel endpoint in the receiving GTP-C entity. The Tunnel 
Endpoint Identifier is set by the sending entity in the GTP header of all control plane messages to the TEID 
value provided by the corresponding receiving entity (see subclause 4.1). If a peer's TEID is not available the 
TEID field shall be present in a GTPv2-C header, but its value shall be set to "0", as specified in subclause 5.5.2 
"Conditions for sending TE1D=0 in GTPv2-C header". 

NOTE: The TEID in the GTP header of a Triggered (or Triggered Reply) message is set to the TEID value 

provided by the corresponding receiving entity regardless of whether the source IP address of the Initial 
(or Triggered) message and the IP Destination Address provided by the receiving entity for subsequent 
control plane Initial messages (see subclause 4.2.2.1) are the same or not. 

- Octets 9 to 1 1 represent GTP Sequence Number field. 

5.5.2 Conditions for sending TEID=0 in GTPv2-C header 

If a peer's TEID is not available, the TEID field still shall be present in the header and its value shall be set to "0" in the 
following messages: 
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- Create Session Request message on S2a/S2b/S5/S8 

- Create Session Request message on S4/S1 1, if for a given UE, the SGSN/MME has not yet obtained the Control 
TEID of the SOW. 

- Create Indirect Data Forwarding Tunnel Request message on S4/S1 1, if the SGW selected by the MME/S4- 
SGSN for indirect data forwarding is different from the SGW used as anchor. 

Identification Request/Response messages. 

- Forward Relocation Request message: over SIO, S16 interfaces, over S3 interface during I-RAT handover when 
ISR is not active. 

- Forward Relocation Request message over S3 interface during 1-RAT handover between ISR associated nodes, 
when ISR is active for the UE, and if the node decides to allocate new S3 TEID-C. 

- Context Request message. 

- Relocation Cancel Request message except for the case where the old SGSN/MME has already been assigned 
the Timnel Endpoint Identifier Control Plane of the new SGSN/MME. 

- Relocation Cancel Response message if the new SGSN/MME does not have the Tunnel Endpoint Identifier 
Control Plane of the old SGSN/MME. 

- Delete PDN Cormection Set Request/Response messages. 

- Configuration Transfer Tunnel message. 
RAN Information Relay message. 

If a node receives a message for which it has no context, i.e. TEID-C is not known, it shall respond with 
"Context not found" Cause in the corresponding response message to the sender, the TEID used in the GTPv2-C 
header in the response message shall be then set to zero. 

- If a node receives a request message containing protocol error, e.g. Mandatory IE missing, which requires the 
receiver to reject the message as specified in clause 7.7, it shall reject the request message. For the response 
message, the node should look up the remote peer"s TEID and accordingly set the GTPv2-C header TEID and 
the message cause code. As an implementation option, the node may not look up the remote peer"s TEID and set 
the GTPv2-C header TEID to zero in the response message. However in this case, the cause code shall not be set 
to "Context not found". 

- MBMS Session Start Request message. 

- PGW Restart Notification / PGW Restart Notification Acknowledge messages. 

- Downlink Data Notification message sent on S11/S4 as part of the Network Triggered Service Restoration 
procedure (see 3GPP TS 23.007 [17]), and corresponding Downlink Data Notification Acknowledge and 
Downlink Data Notification Failure Indication if the SGW did not include the Sender F-TEID for Control Plane 
IE in the Downlink Data Notification message. 

- Suspend Notification and Suspend Acknowledge messages: over S16 interface; over S3 interface when ISR is 
not active. 

- PGW Downlink Triggering Notification message on S5 and SI 1/S4, PGW Downlink Triggering Acknowledge 
message on SI 1/S4, and PGW Downlink Triggering Acknowledge message on S5 if the PGW did not include 
the Sender F-TEID for Control Plane IE in the PGW Downlink Triggering Notification message. 

NOTE: Legacy implementation conforming to earlier versions of this specification can send the Change 
Notification Request/Response messages on the TEID zero in spite of the peer"s node TEID being 
available. 

5.6 Format of the GTPv2-C Message 

The GTP-C header may be followed by subsequent information elements dependent on the type of control plane 
message. 
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Octets 

1 to m 

m+1 to n 



Bits 
5 4 



GTP-C header 



Zero or more Information Elenient(s) 



Figure 5.6-1 : GTP-C Header followed by subsequent Information Elements 
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6 



GTP-C Message Types and Message Formats 



6.0 



General 



A GTP-C message is sent across a GTP control plane tunnel. In a message, the GTP-C header is followed by zero or 
more information elements. The GTP-C messages are used for the control plane path management, for the control plane 
tunnel management and for mobiUty management. 

A T-PDU is an original packet, for example an IP datagram, from an UE, or from a network node in an external packet 
data network. 



GTP defines a set of messages between two associated EPC network elements. The messages to be used shall be as 
defined in Table 6.1-1. 



6.1 



Message Format and Type values 



6.1.0 



Message Type 
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Table 6.1-1 : Message types for GTPv2 
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Delete PDN Connection Set Request 
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Delete PDN Connection Set Response 






X 



ETSI 



3GPP TS 29.274 version 11.5.0 Release 11 



25 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



Message Type 


Message 


Reference 
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Triggered 
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Message Type 
vaiuG ^ueciinaij 


Message 


Reference 


Initial 
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6.1 .1 Presence requirements of Information Elements 

There are four diiJerent presence requirements (Mandatory, Conditional, Optional, or Conditional-Optional) for an IE 
within a given GTP-PDU: 

Mandatory means that the IE shall be included by the sending side, and that the receiver diagnoses a "Mandatory 
IE missing" error, when detecting that the IE is not present. A response including a "Mandatory IE missing" 
cause, shall include the type of the missing IE. 

Conditional means: 

- that the IE shall be included by sending entity if the conditions specified in the relevant protocol specification 
are met; 

the receiver shall check the conditions as specified in the corresponding message type description, based on 
the parameter combination in the message and/or on the state of the receiving node, to infer if a conditional 
IE shall be expected. Only if a receiver has sufficient information the following apphes. A conditional IE, 
which is absolutely necessary for the receiving entity to complete the procedure, is missing, then the receiver 
shall abort the procedure. 

- Conditional-Optional means: 

- that the IE shall be included by the up-to-date sending entity, if the conditions specified in the relevant 
protocol specification are met. An entity, which is at an earUer version of the protocol and therefore is not up- 
to-date, obviously cannot send such new IE. 

- the receiver need not check the presence of the IE in the message. If the receiver checks the presence of the 
Conditional-Optional IE, then the lE's absence shall not trigger any of the error handUng procedures. The 
handling of an absence or erroneous such lEs shall be treated as Optional lEs as specified in subclause 7.7 
"Error Handhng". 

- Optional means: 

that the IE shall be included as a service option. Therefore, the IE may be included or not in a message. The 
handling of an absent optional IE, or an erroneous optional IE is specified in subclause 7.7 "Error Handling". 

For conditional lEs, the clause describing the GTP-PDU explicitly defines the conditions under which the inclusion of 
each IE becomes mandatory or optional for that particular GTP-PDU. These conditions shall be defined so that the 
presence of a conditional IE only becomes mandatory if it is critical for the receiving entity. The definition might 
reference other protocol specifications for final terms used as part of the condition. 

For grouped lEs, the presence requirement of the embedded IE shall follow the rules: 

The grouped IE is Mandatory within a given message: the presence requirements of individual embedded lEs are 
as stated within the Mandatory grouped IE for the given message. 

- The grouped IE is Conditional within a given message: if the embedded IE in the grouped IE is Mandatory or 
Conditional, this embedded IE is viewed as Conditional IE by the receiver. If the embedded IE in the grouped IE 
is Conditional-Optional, this embedded IE is viewed as Optional IE by the receiver. If the embedded IE in the 
grouped IE is Optional, this embedded IE is viewed as Optional IE by the receiver. 
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The grouped IE is Conditional-Optional within a given message: if the embedded IE in the grouped IE is 
Mandatory or Conditional, this embedded IE is viewed as Conditional-Optional IE by the receiver. If the 
embedded IE in the grouped IE is Conditional-Optional, this embedded IE is viewed as Optional IE by the 
receiver. If the embedded IE in the grouped IE is Optional, this embedded IE is viewed as Optional IE by the 
receiver. 

- The grouped IE is Optional within a given message: all embedded lEs in the grouped IE are viewed as Optional 
lEs by the receiver. 

In all of the above cases, appropriate error handling as described in subclause 7.7 shall be applied for protocol errors of 
the embedded lEs. 

Only the Cause information element at message level shall be included in the response if the Cause contains a value that 
indicates that the request is not accepted regardless of whether there are other mandatory or conditional information 
elements defined for a given response message. 

The following are exceptions: 

- Optionally, the Protocol Configuration Options, Recovery, User Location Information (ULI), Bearer Context and 
Local Distinguished Name (LDN) information elements may be included. 

- For the rejection response of a Forward Relocation Request, the Forward Relocation Response message may also 
include an F-Cause IE as specified in clause 7.3.2. 

- For the rejection response of a SRVCC PS to CS Request, the SRVCC PS to CS Response message may also 
include an SRVCC Cause IE as specified in clause 5.2.3 in 3GPP TS 29.280 [15]. 

A Downlink Data Notification Acknowledge (with or) without an indication of success may also include a DL 
low priority traffic Throttling IE and the IMSI IE. 

- The PGW Back-Off Time IE may also be retumed when rejecting a Create Session Request with the cause "APN 
Congestion". 

Change Notification Response message may also include the IMSI and MEl information elements. 

- Failure Indication type messages do not have "Accept" types of cause values i.e. all used values indicate the 
rejection, therefore the preceding rules do not apply. For Failure Indication type of triggered messages, some of 
the Mandatory information elements, other than the Cause IE, may not be included if they are not available. 

6.1.2 Grouped Information Elements 

Information elements can contain other lEs. This type of IE is called "Grouped lEs". 

Grouped lEs have a length value in the TLIV encoding, which includes the added length of all the embedded lEs. 
Overall coding of a grouped information element with 4 octets long IE header is defined in subclause 8.2 "Information 
Element Format". Each information element within a grouped IE also shall also contain 4 octets long IE header. 

Grouped lEs are not marked by any flag or limited to a specific range of IE type values. The clause describing an IE in 
this specification shall explicitly state if it is grouped. 

NOTE 1: Each entry into each Grouped IE creates a new scope level. Exit from the grouped IE closes the scope 
level. The GTPv2 message level is the top most scope. This is analogous to the local scope of a 
subroutine/function. 

If more than one grouped information elements of the same type, but for a different purpose are sent with a message, 
these lEs shall have different Instance values. 

If more than one grouped information elements of the same type and for the same purpose are sent with a message, 
these lEs shall have exactly the same Instance value to represent a list. 

NOTE 2: For instance, all "Bearer Contexts Modified" lEs of the type "Bearer Context" in a "Modify Bearer 

Response" message shall have the Instance value of 0, while all "Bearer Contexts Marked for Removal" 
lEs of the type "Bearer Context" in the same message shall have the Instance value of 1. 
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6.1 .3 Information Element instance 

Every GTPv2 message and grouped IE within a message in this specification has a column documenting the instance 
value of each IE. 

When a GTPv2 message is encoded for use the instance value of each included IE is encoded in the Instance field of the 
IE for the message scope. See clause 7 and subclause 8.2 for details of that encoding. 

An Information Element in an encoded GTPv2 message or encoded grouped IE is identified by the pair of IE Type and 
Instance values and described by a specific row in the corresponding tables in subclauses of 7 in the present document. 

If several Information Elements with the same Type and Instance values are included in an encoded GTPv2 message, 
they represent a list for the corresponding IE name and row identified in the message grannmar in subclauses of clause 
7. 

If several Information Elements with the same Type and Instance values are included in an encoded grouped IE, they 
represent a list for the corresponding IE name and row identified in the grouped IE grammar in subclauses of clause 7. 

In tables in this document the instance value for "Private Extension" is marked as VS (Vendor Specific). While an 
instance value must be encoded by the sender the value can be Vendor and even Private Extension specific. 

The same IE name might be used in different messages (on the top level or within grouped lEs) in this specification. 
The instance value and name of an IE is only meaningful within the scope of the message definition . The combination 
of Type value and Instance value uniquely identifies a specific row in a message description table. 



6.2 Message Granularity 

The GTPv2-C messages shall be sent per UE on the S3, SIO and S16 interfaces. 

The GTPv2-C messages shall be sent per PDN-Connection on the S2a, S2b, S4, Sll, S5 and S8 interfaces apart from 
the following exclusion. 

The following GTPv2-C messages are sent per UE on the S4 and Sll interfaces: 

- Downlink Data Notification / Acknowledge / Failure Indication; 

- Stop Paging Indication; 

Delete Indirect Data Forwarding Tunnel Request/Response; 

Delete Session Request/Response with Scope Indication set to 1 dmng following procedures with SGW change: 

- Tracking Area Update procedure; 

- Routing Area Update procedure; 

- Handover procedure; 

- SRNS Relocation Cancel Using S4; 

- Inter RAT handover Cancel procedure; 

- SI based handover cancel procedure; 

Delete Bearer Request/Response during a TAU/RAU/Handover procedure if the Cause value "ISR deactivation" 
is included in the Delete Session Request message, or when it is sent to delete the bearer resources on the other 
ISR associated CN node if the ISRAI flag is not set in the Modify Bearer Request/Modify Access Bearers 
Request message. 

Release Access Bearers Request/Response; 

Create Indirect Data Forwarding Tunnel Request/Response; 

- Trace Session Activation; 
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- Trace Session Deactivation; 

- Create Forwarding Tunnel Request/Response. 

The following GTPv2-C messages are sent per UE on the S 11 interface: 

- Modify Access Bearers Request/Response. 

7 GTP-C messages 

7.1 Path Management Messages 

7.1.0 General 

Three path management messages are specified for GTP-C: Echo Request, Echo Response and Version Not Supported 
Indication. 

The usage of Echo Request / Response procedure is specified in 3GPP TS 23.007 [17]. 

7.1.1 Echo Request 

Table 7.1.1-1 specifies the information elements included in the Echo Request message. 

The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17]) 
The optional Private Extension contains vendor or operator specific information. 



Table 7.1.1-1: Information Elements in Echo Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Recovery 


M 




Recovery 





Sending Node 
Features 


CO 


This IE shall be sent towards a peer node on any GTPv2 

interface if the sending node supports at least one feature 
on this interface or if the sending node supports at least 
one feature and does not l^now the interface type towards 
the peer node. This IE may be present otherwise. 


Node Features 





Private Extension 







Private Extension 


vs 



7.1.2 Echo Response 

Table 7.1.2-1 specifies the information elements included in the Echo Response message. 

The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17]) 
The optional Private Extension contains vendor or operator specific information. 



Table 7.1.2-1: Information Elements in Echo Response 



Information 
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Condition / Comment 


IE Type 


Ins. 


elements 










Recovery 
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Recovery 





Sending Node 
Features 


CO 


This IE shall be sent towards a peer node on any GTPv2 
interface if the sending node supports at least one feature 
on this interface or if the sending node supports at least 

one feature and does not l<now the interface type towards 
the peer node. This IE may be present otherwise. 


Node Features 





Private Extension 







Private Extension 


VS 
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NOTE: Having no Cause IE in the Echo Response message is an exceptional case for a triggered message. Hence, 
a GTP entity that detects a GTP protocol error, e.g Mandatory IE missing, in the Echo Request message, 
ignores the IE(s) that are in error and sends Echo Response. In addition it can log the error. 



This message contains only the GTPv2 header and indicates the latest GTP version that the sending entity supports. 



A node shall include the Recovery information element if it is in contact with the peer for the first time or the node has 
restarted recently and the new Restart Counter value has not yet been indicated to the peer. The peer receiving the 
Recovery information element shall handle it as when an Echo Response message is received but shall consider the rest 
of the message in accordance with the message semantics and parameters. 

7.2.1 Create Session Request 

The direction of this message shall be from MME/S4-SGSN to SGW and from SGW to PGW, and from ePDG/TWAN 
to the PGW (see Table 6.1-1). 

The Create Session Request message shall be sent on the SI 1 interface by the MME to the SGW, and on the S5/S8 
interface by the SGW to the PGW as part of the procedures: 

- E-UTRAN Initial Attach 

- UE requested PDN connectivity 

The message shall also be sent on S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the SGW to the 
PGW as part of the procedures: 

- PDP Context Activation 

The message shall also be sent on the S 11 interface by the MME to the SGW as part of the procedures: 
Tracking Area Update procedure with Serving GW change 

- S l/X2-based handover with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

- 3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure 

- Gn/Gp SGSN to MME Tracking Area Update procedure 

- Restoration of PDN connections after an SGW failure if the MME and PGW support these procedures as 
specified in 3GPP TS 23.007 [17] 

and on the S4 interface by the SGSN to the SGW as part of the procedures: 

- Routing Area Update with MME interaction and with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update using S4 with SGW 



7.1 .3 Version Not Supported Indication 



7.2 



Tunnel Management Messages 



7.2.0 



General 



change 



- lu mode RA Update Procedure using S4 with SGW change 



- E-UTRAN to UTRAN lu mode hiter RAT handover with SGW change 



ETSI 



3GPP TS 29.274 version 1 1 .5.0 Release 1 1 



31 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 

- Serving RNS relocation using S4 with SGW change 

- Combined hard handover and SRNS relocation using S4 with SGW change 

- Combined Cell / URA update and SRNS relocation using S4 with SGW change 
Enhanced serving RNS relocation with SGW relocation 

- Restoration of PDN connections after an SGW failure if the SGSN and PGW support these procedures as 
specified in 3GPP TS 23.007 [17] 

and on the S2b interface by the ePDG to the PGW as part of the procedures: 

- Initial Attach with GTP on S2b 

UE initiated Connectivity to Additional PDN with GTP on S2b 

- Handover to Untrusted Non-3GPP IP Access with GTP on S2b 
and on the S2a interface by the TWAN to the PGW as part of the procedure: 

- Initial Attach in WLAN on GTP S2a 

If the new Create Session Request message is received by the SGW with TEID in the header for an existing active 
PDN connection context (the existing PDN connection context is identified with the tuple [IMSl, EPS Bearer ID], 
whereas IMSl shall be replaced by ME Identity for emergency attached UE without UlCC or authenticated IMSl), this 
Create Session Request message shall be treated as a request for a new session. The existing PDN connection context 
should be deleted locally, before a new session is created. 

If the new Create Session Request message is received by the PGW with TEID in the header for an existing PDN 
connection context (the existing PDN connection context is identified with the triplet [IMSl, EPS Bearer ID, Interface 
type], whereas applicable Interface type here is S2a TWAN GTP-C interface or S2b ePDG GTP-C interface or S5/S8 
SGW GTP-C interface, and where IMSl shall be replaced by ME Identity for emergency attached UE without UICC or 
authenticated IMSl), this Create Session Request message shall be treated as a request for a new session. The existing 
PDN connection context should be deleted locally, before a new session is created. 

NOTE: With GTP based S2a and S2b, the EPS Bearer IDs assigned for specific UE over S2a between the TWAN 

and PGW and over S2b between an ePDG and PGW are independent of the EPS Bearer IDs assigned for 
the same UE over S5/S8 and may overlap in value (see 3GPP TS 23.402 [45] subclause 4.6.2). 
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Table 7.2.1-1: Information Elements in a Create Session Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 




C 


Tlie IMSI shall be included in ttie message on the S4/S1 1 
interface, and on S5/S8 interface if provided by the 
MME/SGSN, except for the case: 

- If the UE is emergency attached and the UE is 
UlCCIess. 






IMSI 




The IMSI shall be included in the message on the S4/S1 1 
interface, and on S5/S8 interface if provided by the 
MME/SGSN, but not used as an identifier 

if UE is emergency attached but IMSI is not 

authenticated. 

The IMSI shall be included in the message on the S2a/S2b 

interface. 


IMSI 





MSISDN 


C 


For an E-UTRAN Initial Attach the IE shall be included 

when used on the S1 1 interface, if provided in the 

subscription data from the HSS. 

For a PDF Context Activation procedure the IE shall be 

included when used on the S4 interface, if provided in the 

subscription data from the HSS. 

The IE shall be included for the case of a UE Requested 

PDN Connectivity, if the MME has it stored for that UE. 

It shall be included when used on the S5/S8 interfaces if 

provided by the MME/SGSN. 

The ePDG shall include this IE on the S2b interface during 

an Attach with GTP on S2b and a UE initiated Connectivity 
to Additional PDN with GTP on S2b, if provided by the 
HSS/AAA 

The TWAN shall include this IE on the S2a interface during 
an Initial Attach in WLAN on GTP S2a if provided by the 
HSS/AAA. 


MSISDN 







c 


The MME/SGSN shall include the ME Identity (MEI) IE on 
the S11/S4 interface: 

- If the UE is emergency attached and the UE is 
UlCCIess 






ME Identity (MEI) 




- If the UE is emergency attached and the IMSI is not 
authenticated 

For all other cases the MME/SGSN shall include the ME 
Identity (MEI) IE on the S1 1/S4 interface if it is available. 


MEI 







CO 


If the SGW receives this IE, it shall fonward it to the PGW 
on the S5/S8 interface. 






User Location 
Information (ULI) 


c 


This IE shall be included on the S1 1 interface for E- 
UTRAN Initial Attach and UE-requested PDN Connectivity 
procedures. It shall include ECGI&TAI. The MME/SGSN 
shall also include it on the S1 1/S4 interface for 
TAU/RAU/X2-Handover/Enhanced SRNS Relocation 
procedure if the PGW/PCRF has requested location 
information change reporting and MME/SGSN support 
location information change reporting. 


ULI 







CO 


This IE shall also be included on the S4 interface for PDP 
Context Activation procedure. It shall include either the 
CGI or SAI, or CGI/SAI together with RAI. 








CO 


The bGW shall include this IE on S5/S8 if it receives the 
ULI from MME/SGSN. 






Serving Networl< 


C 


This IE shall be included on the S4/S1 1 , S5/S8 and S2b 

interfaces for an E-UTRAN initial attach, a PDP Context 
Activation, a UE requested PDN connectivity, an Attach 
with GTP on S2b, a UE initiated Connectivity to Additional 
PDN with GTP on S2b and a Handover to Untrusted Non- 
3GPP IP Access with GTP on S2b. 


Serving Network 







CO 


This IE shall be included on S4/S1 1 for 
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RAU/TAU/Handover with SGW relocation procedures. 








CO 


The TWAN shall include this IE on the S2a interface and 
set it to the PLIVIN identity of the selected PLMN used for 
3GPP-based access authentication. The selected PLMN is 
the PLIVIN of the 3GPP AAA Proxy in roaming case and 
the PLMN of the 3GPP AAA Server in non-roaming case. 








M 


This IE shall be set to the 3GPP access type or to the value 
matching the characteristics of the non-3GPP access the 
UE is using to attach to the EPS. 






RAT Type 




The ePDG may use the access technology type of the 
untrusted non-3GPP access network if it is able to acquire 
it; otherwise it shall indicate Virtual as the RAT Type. 

The TWAN shall set the RAT Type value to "WLAN" on 
the S2a interface. 

See NOTE 3, NOTE 4. 


RAT Type 







C 


This IE shall be included if any one of the applicable flags 
is set to 1 . 

Applicable flags are: 

S5/S8 Protocol Type: This flag shall be used on 

the S11/S4 interfaces and set according to the 
protocol chosen to be used on the S5/S8 
interfaces. 

Dual Address Bearer Flag: This flag shall be used 
on the S2b, S1 1/S4 and S5/S8 interfaces and shall 
be set to 1 when the PDN Type, determined based 
on UE request and subscription record, is set to 
IPv4v6 and all SGSNs which the UE may be 
handpd nvpr tn ^iinnnrt dual addrp*^c;inn Thi^i Qhall 
be determined based on node pre-configuration by 
the operator, (see also NOTE 5). 
The TWAN shall set this flag to 1 on the S2a 
interface If it supports IPv4 and IPv6 and the PDN 
Type determined from the user subscription data is 
set to IPv4v6. 






Indication Flags 




Handover Indication: This flag shall be set to 1 on 
the S11/S4 and S5/S8 interface during an E- 
UTRAN Initial Attach or a UE Requested PDN 
Connectivity or aPDP Context Activation procedure 
if the PDN connection/PDP Context is handed- 
over from non-3GPP access. 
This flag shall be set to 1 on the S2b interface 
during a Handover to Untrusted Non-3GPP IP 
Access with GTP on S2b and IP address 
preservation is requested by the UE. 

Operation Indication: This flag shall be set to 1 on 
the S4/S1 1 interface for a TAU/RAU procedure 
with SGW relocation. Enhanced SRNS Relocation 
with SGW relocation and X2-based handovers with 
SGW relocation. 

Direct Tunnel Flag: This flag shall be used on the 
S4 interface and set to 1 if Direct Tunnel is used. 

Piggybacking Supported: This flag shall be set to 1 
only if the MME/ SGW supports the piggybacking 
feature as described in Annex F of 3GPP TS 
23.401 [3]. This flag shall be set to 1 on S5/S8 only 
when both the MME and the SGW support 
piggybacking. 

Change Reporting support Indication: shall be 
used on S4/S1 1 , S5/S8 and set if the SGSN/MME 
supports location Info Change Reporting and if the 


Indication 
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SGSN/MME's operator policy permits reporting of 
location change to the operator of the PGW with 
which the session is being established. See 
N0TE2. 

CSG Change Reporting Support Indication: shall 
be used on S4/S1 1 , S5/S8 and set if the 
SGSN/MME supports CSG Information Change 
Reporting and if the SGSN/MME's operator policy 
permits reporting of CSG Information change to 
the operator of the PGW with which the session is 
being established. See NOTE 2. 

Unauthenticated IIVISI: This flag shall be set to 1 
on the S4/S1 1 and S5/S8 interfaces if the IMSI 
present in the message is not authenticated and is 
for an emergency attached UE. 
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Sender F-TEID for 
Control Plane 


M 




F-TEID 





PGW S5/S8 Address 
for Control Plane or 
PMIP 


C 


This IE shall be sent on the S1 1 / S4 interfaces. The TEID 
or GRE Key is set to "0" in the E-UTRAN initial attach, the 
PDP Context Activation and the UE requested PDN 
connectivity procedures. 


F-TEID 


1 


Access Point Name 
(APN) 


M 




APN 







c 


This IE shall be included on the S4/S1 1 and S5/S8 
interfaces for an E-UTRAN initial attach, a PDP Context 
Activation and a UE requested PDN connectivity. 

This IE shall be included on the S2b interface for an Initial 
Attach with GTP on S2b and a UE initiated Connectivity to 
Additional PDN with GTP on S2b. 






Selection IVlode 




It shall indicate whether a subscribed APN or a non 
subscribed APN chosen by the UE/MME/SGSN/ePDG was 
selected. 

This IE shall be included on the S2a interface for an Initial 
Attach in WLAN on GTP S2a. The value shall be set to 
"MS or network provided APN, subscription verified". 


Selection Mode 







CO 


When available, this IE shall be sent by the MME/SGSN on 
the S1 1/S4 interface during TAU/RAU/HO with SGW 
relocation. 






PDN Type 


c 


This IE shall be included on the S4/S1 1 and S5/S8 
interfaces for an E-UTRAN initial attach, a PDP Context 
Activation and a UE requested PDN connectivity. 
This IE shall be set to IPv4, IPv6 or IPv4v6. This is based 
on the UE request and the subscription record retrieved 
from the HSS (for MME see 3GPP TS 23.401 [3], clause 
5.3.1 .1 , and for SGSN see 3GPP TS 23.060 [35], clause 
9.2.1). See NOTE 1. 


PDN Type 







c 


This IE shall be included the S4/S1 1 , S5/S8 and S2a/S2b 
interfaces for an E-UTRAN initial attach, a PDP Context 
Activation, a UE requested PDN connectivity, an Attach 
with GTP on S2b, a UE initiated Connectivity to Additional 
PDN with GTP on S2b, a Handover to Untrusted Non- 
3GPP IP Access with GTP on S2b and an Initial Attach in 
WLAN on GTP S2a. For PIVIIP-based S5/S8, this IE shall 
a|c;n hp inrliidprl nn thp fi4/fi1 1 intprfarp<5 fnr 

ClIOW tJ\^ 1 1 IV^I UU^V^ \JI I LI 1^ I / \J 1 1 III 1^1 1 ClWv70 1 V^l 

TAU/RAU/Handover cases involving SGW relocation. 

The PDN type field in the PAA shall be set to IPv4, or IPv6 
or IPv4v6 by MME, based on the UE request and the 
subscription record retrieved from the HSS (see subclause 
8.12 and also NOTE 5). 






PDN Address 
Allocation (PAA) 




The TWAN shall set the PDN type field in the PAA to IPv4, 
or IPv6 or IPv4v6 based on the IP versions the TWAN 
supports and the PDN type received in the user 
subscription data from the HSS/3GPP AAA Server. 

For static IP address assignment (for MME see 3GPP TS 
23.401 [3], clause 5.3.1 .1 , for SGSN see 3GPP TS 23.060 
[35], clause 9.2.1 , for ePDG see 3GPP TS 23.402 [45] 
subclause 4.7.3, and for TWAN see 3GPP TS 23.402 [45] 
subclause 16.1.5), the MME/SGSN/ePDG/TWAN shall set 
the IPv4 address and/or IPv6 prefix length and IPv6 prefix 
and Interface Identifier based on the subscribed values 
received from HSS, if available. For PDN Type IPv4v6, 
either one of the IP versions (i.e. IPv4 address or IPv6 
prefix and Interface Identifier) or both the IP versions may 
be statically provisioned in the HSS. if only one of the IP 
versions is statically provisioned in the HSS, the 
MME/SGSN/ePDG/TWAN shall set the other IP version as 
all zeros. The value of PDN Type field shall be consistent 


PAA 






ETSI 



3GPP TS 29.274 version 11.5.0 Release 11 



36 



ETSI TS 129 274 V1 1.5.0 (2013-01) 







witfn the value of the PDN Type IE, if present in this 

message. 










For a Handover to Untrusted Non-3GPP IP Access with 
GTP on S2b, the ePDG shall set the IPv4 address and/or 
IPv6 prefix length and IPv6 prefix and Interface Identifier 
based on the IP address(es) received from the UE. 










If static IP address assignment is not used (e.g. static 
address is not received from the HSS), and for scenarios 
other than a Handover to Untrusted Non-3GPP IP Access 
with GTP on S2b, the IPv4 address shall be set to 0.0.0.0, 
and/or the IPv6 Prefix Length and IPv6 prefix and Interface 
Identifier shall all be set to zero. 








CO 


This IE shall be sent by the MME/SGSN on S1 1/S4 
interface during TAU/RAU/HO with SGW relocation. 






Maximum APN 
Restriction 


C 


This IE shall be included on the S4/S1 1 and S5/S8 
interfaces in the E-UTRAN initial attach, PDP Context 
Activation and UE Requested PDN connectivity 
procedures. 

This IE denotes the most stringent restriction as required 
by any already active bearer context. If there are no 
already active bearer contexts, this value is set to the least 
restrictive type. 


APN Restriction 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


C 


This IE represents the APN-AMBR. It shall be included on 
the S4/S1 1 , S5/S8 and S2a/S2b interfaces for an E- 
UTRAN initial attach, UE requested PDN connectivity, PDP 
Context Activation procedure using S4, PS mobility from 
the Gn/Gp SGSN to the S4 SGSN/MME procedures. 
Attach with GTP on S2b, UE initiated Connectivity to 
Additional PDN with GTP on S2b, and Initial Attach in 
WLAN on GTP S2a. 


AMBR 





Linl<ed EPS Bearer ID 


C 


This IE shall be included on S4/S1 1 in RAU/TAU/HO 

except in the Gn/Gp SGSN to MME/S4-SGSN 
RAU/TAU/HO procedures with SGW change to identify the 
default bearer of the PDN Connection 


EBI 





Protocol 
Configuration Options 
(PCO) 


C 


This IE is not applicable to TAU/RAU/Handover. If 
MME/SGSN receives PCO from UE (during the attach or 
PDN connectivity procedures), the MME/SGSN shall 
forward the PCO IE to SGW. The SGW shall also forward 
it to PGW. 


PCO 





Bearer Contexts to be 
created 


M 


Several lEs with the same type and instance value shall be 
included on the S4/S1 1 and S5/S8 interfaces as necessary 
to represent a list of Bearers. One single IE shall be 
included on the S2a/S2b interface. 
One bearer shall be included for E-UTRAN Initial Attach, 
PDP Context Activation, UE requested PDN Connectivity, 
Attach with GTP on S2b, UE initiated Connectivity to 
Additional PDN with GTP on S2b, Handover to Untrusted 
Non-3GPP IP Access with GTP on S2b, and Initial Attach 
in WLAN on GTP S2a. 
One or more bearers shall be included for a 
Handover/TAU/RAU with an SGW change. 


Bearer Context 





Bearer Contexts to be 
removed 


C 


This IE shall be included on the S4/S1 1 interfaces for the 
TAU/RAU/Handover cases where any of the bearers 
existing before the TAU/RAU/Handover procedure will be 
deactivated as consequence of the TAU/RAU/Handover 
procedure. 

For each of those bearers, an IE with the same type and 
instance value shall be included. 


Bearer Context 


1 


Trace Information 


C 


This IE shall be included on the S4/S1 1 interface if an 
bGW trace is activated, and/or on the bo/bo and b od.a/<iu 
interfaces if a PGW trace is activated. See 3GPP TS 
32.422 [18]. 


Trace Information 





Recovery 


C 


This IE shall be included on the S4/S1 1 , S5/S8 and S 
S2a/2b interfaces if contacting the peer node for the first 
time. 


Recovery 





MME-FQ-CSID 


C 


This IE shall be included by the MME on the S1 1 interface 


FQ-CSID 
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and shall be forwarded by an SGW on the S5/S8 interfaces 
according to the requirements in 3GPP TS 23.007 [17]. 






SGW-FQ-CSID 


C 


This IE shall included by the SGW on the S5/S8 interfaces 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


ePDG-FQ-CSID 


C 


This IE shall be included by the ePDG on the S2b interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


2 


TWAN-FQ-CSID 





This IE shall be included by the TWAN on the S2a 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 


3 


UE Time Zone 


CO 


This IE shall be included by the MME over S1 1 during 
Initial Attach, UE Requested PDN Connectivity procedure. 
This IE shall be included by the SGSN over S4 during PDP 

Context Activation procedure. 

This IE shall be included by the MME/SGSN over SI 1/S4 
TAU/RAU/Handover with SGW relocation. 


UE Time Zone 





C 


If SGW receives this IE, SGW shall forward it to PGW 
across S5/S8 interface. 


User CSG 
Information (UCI) 


CO 


This IE shall be included on the S4/S1 1 interface for E- 
UTRAN Initial Attach, UE-requested PDN Connectivity and 
PDP Context Activation using S4 procedures if the UE is 
accessed via CSG cell or hybrid cell. The MME/SGSN 
shall also include it for Handover procedures with SGW 
relocation if the PGW/PCRF has requested CSG info 
reporting and MME/SGSN support CSG info reporting. 
In TAU/RAU procedure with the SGW change, the 
MME/SGSN shall also include this IE if the PGW has 
requested CSG info reporting and MME support CSG info 
reporting and UE requested to active E-RAB for all the 
active EPS bearers in TAU procedure or to keep the lu 
connection after the completion of the RAU procedure. 
The SGW shall include this IE on S5/S8 if it receives the 
User CSG information from MME/SGSN. 


UCI 





Charging 
Characteristics 


C 


This IE shall be included on the S4/S1 1 , S5/S8 and 
S2a/S2b interfaces according to 3GPP TS 32.251 [8] 


Charging 
Characteristics 





I\/1I\/1E/S4-SGSN LDN 





This IE is optionally sent by the MME to the SGW on the 
S1 1 interface and by the S4-SGSN to the SGW on the S4 
interface (see 3GPP TS 32.423 [44]), when communicating 
the LDN to the peer node for the first time. 


Local 
Distinguished 
Name (LDN) 





SGW LDN 





This IE is optionally sent by the SGW to the PGW on the 
S5/S8 interfaces (see 3GPP TS 32.423 [44]), when 
communicating the LDN to the peer node for the first time. 


Local 
Distinguished 
Name (LDN) 


1 


ePDG LDN 





This IE is optionally sent by the ePDG to the PGW on the 
S2b interfaces (see 3GPP TS 32.423 [44]), when 
contacting the peer node for the first time. 


Local 
Distinguished 

Name (LDN) 


2 


TWAN LDN 





This IE may be sent by the TWAN to the PGW on the S2a 
interfaces (see 3GPP TS 32.423 [44]), when contacting the 
peer node for the first time. 


Local 
Distinguished 
Name (LDN) 


3 


Signalling Priority 
Indication 


CO 


The SGSN/MME shall include this IE on the S4/S1 1 
interface if the UE indicates low access priority when 
requesting to establish the PDN connection. 
The SGW shall forward this IE in the Create Session 
Request message on the S5/S8 interfaces if received from 
the MME/SGSN. 


Signalling Priority 
Indication 





UE Local IP Address 


CO 


The ePDG shall include this IE on S2b interface based on 
local policy for Fixed Broadband access network 
interworking see 3GPP in TS 23.139 [51]. 


IP Address 





UE UDP Port 


CO 


The ePDG shall include this IE on S2b interface if NAT is 
detected and UE Local IP Address is present for Fixed 
Broadband access network interworking see 3GPP in TS 
23.139 [51]. 


Port Number 





Additional Protocol 
Configuration Options 
(APCO) 


CO 


If multiple authentications are supported by the ePDG, the 
ePDG shall include this IE on the S2b interface and 

perform the corresponding procedures as specified for 
PAP and CHAP authentication of the UE with external 
networks in 3GPP TS 33.402 [50]. 


Additional 
Protocol 
Configuration 
Options (APCO) 








If the UE requests the DNS IPv4/IPv6 address in the 
Configuration Payload (CFG_REQ) during the IPsec tunnel 
establishment procedure (as specified in 3GPP TS 33.402 
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O 



[50]), and if the ePDG supports the Additional Protocol 
Configuration Options IE, the ePDG may include this IE 
over S2b interface and correspondingly set the "DNS 
Server IPv4/v6 Address Request" parameter as defined in 
3GPP TS 24.008 [5], 



The TWAN may include this IE on the S2a interface to 
retrieve additional IP configuration parameters from the 

PGW (e.g. DNS server). 



GO 



H(e)NB Local IP 
Address 



The IVIIVIE/SGSN shall include this IE on SI 1/S4 interface if 
the IVIME/SGSN receives this information from H(e)NB in 
UE associated S1/lu signalling according (see 3GPP TS 
23.139 [51]) during: 

E-UTRAN Initial Attach, UE-requested PDN 
Connectivity and PDP Context Activation using S4; 
TAU/RAU/X2-based handover/Enhanced Serving 
RNS Relocation Procedure with SGW change, if 
the PGW/PCRF has requested H(e)NB information 
reporting for the PDN connection. 

The SGW shall forward this IE on S5/S8 interface if the 
SGW receives it from the MME/SGSN. 



IP Address 



CO 



H(e)NB UDP Port 



The MME/SGSN shall include this IE on S11/S4 interface if 
the MME/SGSN receives this information from H(e)NB in 
UE associated Sl/lu signalling according (see 3GPP TS 
23.139 [51]) during: 

E-UTRAN Initial Attach, UE-requested PDN 
Connectivity and PDP Context Activation using S4; 
TAU/RAU/X2-based handover/Enhanced Serving 
RNS Relocation Procedure with SGW relocation, if 
the PGW/PCRF has requested H(e)NB information 
reporting for the PDN connection. 

The SGW shall forward this IE on S5/S8 interface if the 

SGW receives it from the MME/SGSN. 



Port Number 



CO 



MME/S4-SGSN 
Identifier 



If the PGW triggered SGW restoration procedure is 
supported, the MME/S4-SGSN shall include this IE on 
S1 1/S4 interface and the SGW shall fonward this IE on S5 
interface in the existing signalling as specified in 3GPP TS 
23.007 [17]. 



IP Address 



TWAN Identifier 



This IE may be included on the S2a interface for Initial 
Attach in WLAN procedure as specified in 3GPP TS 
23.402 [45]. If present, it should contain the BSSID and 
may contain the SSID of the access point to which the UE 
is attached. 



TWAN Identifier 



Private Extension 



O 



This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 



Private Extension 



VS 



NOTE 1 : The conditional PDN Type IE is redundant on the S4/S1 1 and S5/S8 interfaces (as the PAA IE 

contains exactly the same field). The receiver may ignore it. This IE is never sent on the S2a/S2b 
interface. 

NOTE 2: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1 ) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1 ) 

defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In 
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change 
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change 
Reporting Support Indication. 

NOTES: The methods that the ePDG may use to acquire the RAT type of the untrasted non-3GPP IP access 

network are not specified in this release. 



N0TE4: The PDN-GW can be informed about the type of access network used by the UE over several 
reference points, see 3GPP TS 29.212 [30] for the mapping between the code values for the 
different access network types. 

N0TE5: 3GPP TS 23.401 [3] (see subclause 5.3.1 .1) and 3GPP TS 23.060 [35] (see subclause 9.2.1) specify 
the handling of the cases when UE has requested IPv4v6 PDN Type, but MME does not set the Dual 
Address Bearer Flag due to the MME operator using single addressing per bearer to support 

intenworking with nodes of earlier releases. 
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Table 7.2.1-2: Bearer Context to be created within Create Session Request 





Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


^^^^^^^m = " ^^^^^^^^^^^^^^^^^^^ 


0©tSt4 


^^^^^^Hl^pare and.lnstanc^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 





This IE may be Included on the S4/S1 1 interfaces. 


Bearer TFT 





S1-U eNodeB F-TEID 


C 


This IE shall be included on the S1 1 interface for X2-based 
handover with SGW relocation. 


F-TEID 





S4-U SGSN F-TEID 


C 


This IE shall be included on the S4 interface if the S4-U 

Interface Is used. 


F-TEID 


1 


S5/S8-U SGW F- 
TEID 


C 


This IE shall be Included on the S5/S8 interface for an 
"ellTRAN Initial Attach", a "PDP Context Activation" or a 
"UE Requested PDN Connectivity". 


F-TEID 


2 


S5/S8-U PGW F- 
TEID 


C 


This IE shall be included on the S4 and S1 1 interfaces for 
the TAU/RAU/Handover cases when the GTP-based 

85/88 Is used. 


F-TEID 


3 


S12 RNC F-TEID 


CO 


This IE shall be Included on the 84 Interface If the 812 
Interface is used in the Enhanced serving RNS relocation 
with SGW relocation procedure. 


F-TEID 


4 


S2b-U ePDG F-TEID 


C 


This IE shall be included on the S2b interface for an Attach 
with GTP on S2b, a UE initiated Connectivity to Additional 
PDN with GTP on 82b and a Handover to Untrusted Non- 
3GPP IP Access with GTP on 82b. 


F-TEID 


5 


S2a-U TWAN F-TEID 


C 


This IE shall be Included on the S2a interface for an Initial 

Attach In WLAN on GTP S2a. 


F-TEID 


6 


Bearer Level QoS 


M 




Bearer QoS 





Table 7.2.1-3: Bearer Context to be removed within Create Session Request 


Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Detet 4 






Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





S4-U SGSN F-TEID 


C 


This IE shall be sent on the 84 interface if the S4-U 
interface Is used. See NOTE 1 . 


F-TEID 





NOTE 1 : The conditional S4-U SGSN F-TEID IE is redundant. 



7.2.2 Create Session Response 

The Create Session Response message shall be sent on the SI 1 interface by the SGW to the MME, and on the S5/S8 
interface by the PGW to the SGW as part of the procedures: 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 

The message shall also be sent on S4 interface by the SGW to the SGSN, and on the S5/S8 interface by the PGW to the 
SGW as part of the procedures: 

- PDP Context Activation 

The message shall also be sent on the S 1 1 interface by the SGW to the MME as part of the procedures: 

- Tracking Area Update procedure with SGW change 

- Sl/X2-based handover with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 
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- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

- 3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure 

- Gn/Gp SGSN to MME Tracking Area Update procedure 

- Restoration of PDN connections after an SGW failure if the MME and PGW support these procedures as 
specified in 3GPP TS 23.007 [17] 

and on the S4 interface by the SGW to the SGSN as part of the procedures: 

- Routing Area Update with MME interaction and with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update using S4 with SGW 
change 

- lu mode RA Update Procedure using S4 with SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 

- Serving RNS relocation using S4 with SGW change 

- Combined hard handover and SRNS relocation using S4 with SGW change 

- Combined Cell / URA update and SRNS relocation using S4 with SGW change 

- Enhanced serving RNS relocation with SGW relocation 

- Restoration of PDN connections after an SGW failure if the SGSN and PGW support these procedures as 
specified in 3GPP TS 23.007 [17] 

and on the S2b interface by the PGW to the ePDG as part of the procedures: 

- Initial Attach with GTP on S2b 

UE initiated Connectivity to Additional PDN with GTP on S2b 
Handover to Untrusted Non-3GPP IP Access with GTP on S2b 
and on the S2a interface by the PGW to the TWAN as part of the procedure: 

- Initial Attach in WLAN on GTP S2a 

If handling of default bearer fails, then cause at the message level shall be a failure cause. 
Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially" . 

"New PDN type due to network preference" . 

"New PDN type due to single address bearer only". 

"Missing or unknown APN" . 

- "GRE key not found". 
"Preferred PDN type not supported" . 
"AH dynamic addresses are occupied". 
"Remote peer not responding" . 
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"Semantic error in the TFT operation" . 
"Syntactic error in the TFT operation" . 
"Semantic errors in packet filter(s)". 
"Syntactic errors in packet filter(s)". 
"User authentication failed". 
"APN access denied - no subscription". 

"APN Restriction type incompatibility with currently active PDN Connection". 
"Version not supported by next peer" . 

- "Denied in RAT". 
"Protocol type not supported". 

- "APN congestion". 

- "Multiple PDN connections for a given APN not allowed" . 
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Table 7.2.2-1 : Information Elements in a Create Session Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


IVI 


See NOTE 2 and NOTE 4. 


Cause 





Change Reporting 
Action 


C 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field if the location 
Change Reporting mechanism is to be started or stopped 
for this subscriber in the SGSN/IVIIVIE. 


Change Reporting 
Action 





CSG Information 
Reporting Action 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field if the CSG Info 
reporting mechanism is to be started or stopped for this 
subscriber in the SGSN/MME. 


CSG Information 
Reporting Action 





H(e)NB Information 
Reporting 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field if H(e)NB 
information reporting is to be started or stopped (during a 
TAU/RAU with SGW change if started earlier) for the PDN 
connection in the SGSN/MME. 


H(e)NB 
Information 
Reporting 





Sender F-TEID for 
Control Plane 


c 


This IE shall be sent on the S1 1/S4 interfaces. For the 
S5/S8/ S2a/S2b interfaces it is not needed because its 
content would be identical to the IE PGW S5/S8/ S2a/S2b 
F-TEID for PMIP based interface or for GTP based Control 
Plane interface. 


F-TEID 





PGW S5/S8/ S2a/S2b 
F-TEID for PMIP 
based interface or for 
GTP based Control 
Plane interface 


c 


The PGW shall include this IE on the S5/S8 interfaces 

during the Initial Attach, UE requested PDN connectivity 

and PDP Context Activation procedures. 

If the SGW receives this IE it shall forward the IE to 

MME/S4-SGSN on S11/S4 interaface. 

This IE shall include the TEID in the GTP based S5/S8 

case and the GRE key in the PMIP based S5/S8 case. 

In PMIP based S5/S8 case, same IP address is used for 

both control plane and the user plane communication. 

The PGW shall include this IE on the S2b interface during 
the Attach with GTP on S2b, UE initiated Connectivity to 
Additional PDN with GTP on S2b and Handover to 
Untrusted Non-3GPP IP Access with GTP on S2b 
procedures. 

The PGW shall include this IE on the S2a interface during 
the Initial Attach in WLAN on GTP S2a procedure. 


F-TEID 


1 


PDN Address 
Allocation (PAA) 


c 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces for the E-UTRAN initial attach, PDP 
Context Activation, UE requested PDN connectivity. Attach 
with GTP on S2b, UE initiated Connectivity to Additional 
PDN with GTP on S2b, Handover to Untrusted Non-3GPP 
IP Access with GTP on S2b, and Initial Attach in WLAN on 
GTP S2a procedures. 

The PDN type field in the PAA shall be set to IPv4, or IPv6 
or IPv4v6 by the PGW. See N0TE4. 
For the S4/S1 1 and S5/S8 interfaces, if the PGW uses 
DHCPv4 for IPv4 address allocation, the IPv4 address field 
shall be set to 0.0.0.0; otherwise, the IPv4 address field 
shall be set to non-zero value as specified in 3GPP TS 
23.401 [3] and 3GPP TS 23.402 [45]. 


PAA 





APN Restriction 


c 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces in the E-UTRAN initial attach, PDP Context 
Activation and UE Requested PDN connectivity 
procedures. 

This IE shall also be included on S4/S1 1 during the Gn/Gp 

SGSN to S4 SGSN/MME RAU/TAU procedures. 

This IE denotes the restriction on the combination of types 

of APN for the APN associated with this EPS bearer 

Context. 


APN Restnction 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


c 


This IE represents the APN-AMBR. It shall be included on 
the S5/S8, S4/S1 1 and S2a/S2b interfaces if the received 
APN-AMBR has been modified by the PCRF. 


AMBR 





Linked EPS Bearer ID 


c 


This IE shall be sent on the S4/S1 1 interfaces during 


EBI 
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Gn/Gp SGSN to S4-SGSN/MME RAU/TAU procedure to 
identify the default bearer the PGW selects for the PDN 
Connection. 






Protocol 

Configuration Options 
(PCO) 


C 


This IE is not applicable for TAU/RAU/Handover. If PGW 
decides to return PCO to the UE, PGW shall send PCO to 
SGW. If SGW receives the PCO IE, SGW shall forward it 
to MME/SGSN. 


PCO 





Rparpr Contf^Xt*? 

created 


M 


EPS bearers corresponding to Bearer Contexts sent in 
request message. Several lEs with the same type and 
instance value may be included on the S5/S8 and S4/S1 1 
as necessary to represent a list of Bearers. One single IE 
shall be included on the S2a/S2b interface. 
One bearer shall be included for E-UTRAN Initial Attach, 
PDP Context Activation, UE Requested PDN Connectivity , 
Attach with GTP on S2b, UE initiated Connectivity to 
Additional PDN with GTP on S2b, Handover to Untrusted 
Non-3GPP IP Access with GTP on S2b, Initial Attach in 
WLAN on GTP S2a. 

One or more created bearers shall be included for a 

Handover/TAU/RAU with an SGW change. See NOTE 2. 


Bearer Context 





Bearer Contexts 
marked for removal 


C 


EPS bearers corresponding to Bearer Contexts to be 
removed that were sent in the Create Session Request 
message. 

For each of those bearers an IE with the same type and 
instance value shall be included on the S4/S1 1 interfaces. 


Bearer Context 


1 


Recovery 


C 


This IE shall be included on the S4/S1 1 , S5/S8 and 
S2a/S2b interfaces if contacting the peer for the first time 


Recovery 





Charging Gateway 
Name 


C 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface. 
See NOTE 1 . 


FQDN 





Cliarging Gateway 
Address 


C 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface. See NOTE 1. 


IP Address 





PGW-FQ-CSID 


c 


This IE shall be included by the PGW on the S5/S8 and 
S2a/S2b interfaces and, when received from S5/S8 be 
forwarded by the SGW on the S1 1 interface according to 
the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by the SGW on the S1 1 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


SGW LDN 





This IE is optionally sent by the SGW to the MME/SGSN 
on the S1 1/S4 interfaces (see 3GPP TS 32.423 [44]), 
when communicating the LDN to the peer node for the first 
time. 


Local 

Distinguished 
Name (LDN) 





PGW LDN 





This IE is optionally included by the PGW on the S5/S8 
and S2a/S2b interfaces (see 3GPP TS 32.423 [44]), when 
communicating the LDN to the peer node for the first time. 


Local 
Distinguished 
Name (LDN) 


1 


PGW Back-Off Time 





This IE may be included on the S5/S8 and S4/S1 1 
interfaces when the PDN GW rejects the Create Session 
Request with the cause "APN congestion". It indicates the 
time during which the MME or S4-SGSN should refrain 
from sending subsequent PDN connection establishment 
requests to the PGW for the congested APN for services 
other than Service Users/emergency services. 
See NOTE 3. 


EPC Timer 





Additional Protocol 
Configuration Options 
(APCO) 


CO 


If multiple authentications are supported by the PGW and if 
PGW received the Additional Protocol Configuration 

Options IE in the Create Session Request, the PGW shall 
include this IE on the S2b interface and perform the 
corresponding procedures as specified for PAP and CHAP 
authentication of the UE with external networks in 3GPP 
TS 33.402 [50]. 


Additional 
Protocol 
Configuration 
Options (APCO) 








If the PGW supports the Additional Protocol Configuration 
Options IE and if the PGW has received the Additional 
Protocol Configuration Options IE with the "DNS IPv4/IPv6 
Server Address Request" parameter in the Create Session 
Request over S2b interface, the PGW may include this IE 
over the S2b interface with the "DNS IPv4/IPv6 Server 
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Address" parameter as specified in 3GPP TS 24.008 [5]. 









The PGW may include this IE on the S2a interface to 
provide the TWAN with additional IP configuration 
parameters (e.g. DNS server), if a corresponding request 
was received in the Create Session Request message. 


Trusted WLAN IPv4 
Parameters 


CO 


The PGW shall include this IE on the S2a interface to a 
Trusted WLAN Access if PDN Type in the PAA is set to 
IPv4 or IPv4v6 and shall include: 

The Subnet Prefix Length of the subnet from which 
the PGW allocates the UE"s IPv4 address. 

The IPv4 Default Router Address which belongs 
tothe same subnet as the IPv4 address allocated 
to the UE. 


IPv4 
Configuration 
Parameters 
(IP4CP) 





Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


VS 


N0TE1 : Botli Charging Gateway Name and Charging Gateway Address shall not be included at the same 

time. When both are available, the operator configures a preferred value. 
N0TE2: If the SGW cannot accept any of the "Bearer Context Created" lEs within Create Session Request 

message, the SGW shall send the Create Session Response with appropriate reject Cause value. 
NOTE 3: The last received value of the PGW Back-Off Time IE shall supersede any previous values received 

from that PGW and for this APN in the MME/SGSN. 
N0TE4: 3GPP TS 23.401 [3] (see subclause 5.3.1.1) and 3GPP TS 23.060 [35] (see subclause 9.2.1) specify 

the handling of the cases when UE has requested IPv4v6 PDN Type, but PGW restricts the usage of 

IPv4v6 PDN Type. 
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Table 7.2.2-2: Bearer Context Created within Create Session Response 



Uctets 1 


Bearer Context IE Type = 93 (decimal) 


Uctets li and o 


^^^^^^^^^^ = n 




■^^^^^^^^^pare Instancj^^^^^^^^^^^^^^^^^^ft 


Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


EPb Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, it gives information on the reason. (NOTE 1 , 
NOTE 2, NOTE 3) 


Cause 





TFT 





NOTE 4. 


Bearer TFT 





S1-USGWF-TEID 


C 


This IE shall be included on the S1 1 interface if the S1-U 

interface is used. 


F-TEID 





S4-U SGW F-TEID 


C 


This IE shall be included on the S4 interface if the S4-U 
interface is used. 


F-TEID 


1 


S5/S8-U PGW F- 
TEID 


c 


For GTP-based S5/S8, this User Plane IE shall be included 

on S4/S11 and S5/S8 interfaces during the "eUTRAN Initial 
Attach", a "PDP Context Activation" or a "UE Requested 
PDN Connectivity". 


F-TEID 


2 


S12 SGW F-TEID 


c 


This IE shall be included on the S4 interface if the SI 2 
interface is used. 


F-TEID 


3 


S2b-U PGW F-TEID 


c 


This IE (for user plane) shall be included on the S2b 
interface during the Attach with GTP on S2b, UE initiated 

Connectivity to Additional PDN with GTP on S2b, and 
Handover to Untrusted Non-3GPP IP Access with GTP on 
S2b. 


F-TEID 


4 


S2a-U PGW F-TEID 


c 


This IE (for user plane) shall be included on the S2a 
interface during the Initial Attach in WLAN on GTP S2a. 


F-TEID 


5 


Bearer Level QoS 


c 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces if the received QoS parameters have 
been modified. 


Bearer QoS 







c 


This IE shall be included on the S5/S8 interface for an E- 
UTRAN initial attach, a PDP Context Activation and a UE 
requested PDN connectivity. 






Charging Id 





If the S5/S8 interface is GTP, this IE may be included on 

the S4 interface, in order to support CAMEL charging at 
the SGSN, for a PDP Context Activation, inter S4-SGSN 
RAU with SGW change and Gn/Gp to S4-SGSN RAU. 


Charging Id 







CO 


This IE shall be included on the S2a/S2b interface for an 
Initial Attach in WLAN on GTP S2a, Attach with GTP on 
S2b, UE initiated Connectivity to Additional PDN with GTP 
on S2b, and Handover to Untrusted Non-3GPP IP Access 
with GTP on S2b. 






Bearer Flags 





Applicable flags are: 

PPC (Prohibit Payload Compression) : this flag 
may be set on the S5/S8 and S4/S1 1 interfaces. 


Bearer Flags 





NOTE 1 : According to 3GPP TS 23.401 [3] e.g. subclause 5.5.1 .2.2 "SI -based handover, normal" and 3GPP 
TS 23.060 [35], during the handover procedure with an SGW change, except in the case of X2- 
handover (N0TE2 addresses X2 based HO with SGW change case), the target l\/IME/S4-SGSN 
initiates the Create Session Request/Response and Modify Bearer Request/Response procedures 
one after the other. After receiving the "Bearer Context to be Created" lEs within Create Session 
Request message, the SGW may not accept some of these bearers. The SGW however shall return 
all bearers with the "Bearer Context Created" lEs within Create Session Response message (this 
table), but with different Cause values. Bearers that were not accepted by the SGW shall have an 
appropriate rejection value in the Cause IE. The target MME/S4-SGSN shall send these non- 
accepted bearers to the target SGW within the "Bearer Context to be removed" IE in a subsequent 
Modify Bearer Request message. Therefore, the SGW shall allocate the DL S5/S8 SGW F-TEIDs 
also for the non-accepted bearers. MME/S4-SGSN should remove all of the non-accepted bearers by 
separate procedures (e.g. an MME/S4-SGSN initiated Dedicated Bearer Deactivation procedure). 

NOTE 2: According to 3GPP TS 23.401 [3] subclause 5.5.1 .1 .3, "X2-based handover with Serving GW 

relocation", and 3GPP TS 23.060 [35] subclause 6.9.2.2.5A "Enhanced Serving RNS Relocation 
Procedure using S4", during the X2-handover procedure with an SGW change and Enhanced 
Serving RNS Relocation Procedure with an SGW change, the target MME/S4-SGSN shall initiate 
only the Create Session Request/Response procedure. The SGW shall return all bearers (including 
those not accepted by the SGW) with a "Bearer Context Created" IE within Create Session 
Response message (this table), but with different Cause values. Bearers that were not accepted by 



ETSI 



3GPP TS 29.274 version 11.5.0 Release 11 



46 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



the SGW shall have an appropriate rejection value in the Cause IE, The MME/S4-SGSN should 
remove these non-accepted bearers by separate procedures as well. 
NOTE 3: According to 3GPP TS 23.401 [3] e.g. subclause 5.3.3.1 "Tracking Area Update procedure with 
Serving GW change" and 3GPP TS 23.060 [35], during the RAU/TAU procedure with an SGW 
change, the target IV1ME/S4-SGSN shall initiate only the Create Session Request/Response 
procedure. The SGW shall return all bearers (including those not accepted by the SGW) with a 
"Bearer Context Created' IE within Create Session Response message (this table), but with different 
Cause values. Bearers that were not accepted by the SGW shall have an appropriate rejection value 
in the Cause IE. When Active Flag or Follow-on request is set during TAU/RAU procedure, MME/S4- 
SGSN should not establish user plane tunnel over SI or lu for those bearer contexts which were not 
accepted by the target SGW, while in the corresponding Modify Bearer Request message, the 
IVIME/S4-SGSN shall include all accepted bearer contexts in the "Bearer Context to be modified" IE 
and include all non-accepted bearer contexts in the "Bearer Context to be removed" IE. The 
MME/S4-SGSN should remove the bearers non-accepted by either SGW or eNB/RNC by separate 
procedures as well. 

N0TE4: The applicability of this IE over S2b interface is FFS, pending on the requirement clarification by 
stage 2. This IE is not applicable over all the other interfaces and hence shall not be included. 



Table 7.2.2-3: Bearer Context marked for removal within a Create Session Response 





Octets 2 and 3 


Length = n 


Octet 4 


Scare and Instance fields 


Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










EPS Bearer ID 


IVl 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives the information on the reason. 


Cause 






7.2.3 Create Bearer Request 

The direction of this message shall be from PGW to SGW and from SGW to MME/S4-SGSN, and from PGW to 
TWAN/ePDG (see Table 6.1-1). 

The Create Bearer Request message shall be sent on the S5/S8 interface by the PGW to the SGW and on the SI 1 
interface by the SGW to the MME as part of the Dedicated Bearer Activation procedure. 

The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
the SGSN as part of the Secondary PDP Context Activation procedure or the Network Requested Secondary PDP 
Context Activation procedure. 

The message shall also be sent on the S2a interface by the PGW to the TWAN as part of the Dedicated bearer activation 
in WLAN on GTP S2a, and on the S2b interface by the PGW to the ePDG as part of the Dedicated S2b bearer 
activation with GTP on S2b. 
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Table 7.2.3-1 : Information Elements in a Create Bearer Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Procedure 
Transaction Id (PTI) 


C 


This IE shall be sent on the S5/S8 and S4/S1 1 interfaces 
when the procedure was initiated by a UE Requested 
Bearer Resource Modification Procedure or UE Requested 
Bearer Resource Allocation Procedure (see NOTE 1) or 
Secondary PDP Context Activation Procedure. 
The PTI shall be the same as the one used in the 
corresponding Bearer Resource Command. 


PTI 





United Bearer Identity 
(LBI) 


M 


This IE shall be included to indicate the default bearer 
associated with the PDN connection. 


EBI 





Protocol 

Configuration Options 
(PCO) 





This IE may be sent on the S5/S8 and S4/S1 1 interfaces. 


PCO 





Bearer Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 





PGW-FQ-CSID 


C 


This IE shall be included by the PGW on the S5/S8 and 

S2a/S2b interfaces and, when received from S5/S8 be 
forwarded by the SGW on the S1 1 interface according to 
the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by the SGW on the S1 1 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Change Reporting 
Action 


C 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field If the location 
Change Reporting mechanism is to be started or stopped 
for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





CSG Information 
Reporting Action 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field if the CSG Info 
reporting mechanism is to be started or stopped for this 

subscriber in the SGSN/MME. 


CSG Information 
Reporting Action 





H(e)NB Information 
Reporting 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field if H(e)NB 
information reporting is to be started or stopped for the 
PDN connection in the SGSN/MME. 


H(e)NB 
Information 
Reporting 





Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


vs 


NOTE 1 : This message refers to the UE requested bearer resource allocation procedure and UE requested 
bearer resource modification procedures defined in 3GPP TS 24.301 [23], both are specified in 
3GPP TS 23.401 [3] in the clause "UE requested bearer resource modification". 



NOTE: In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure 
or a UE Requested Bearer Resource Allocation Procedure or Secondary PDP Context Activation 
Procedure, then there will be only one instance of the Bearer Contexts IE in the Create Bearer Request. 
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Table 7.2.3-2: Bearer Context within Create Bearer Request 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Uctets and o 






^^^^^^^^^pare and.lnstanc^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 


This IE shall be set to 0. 


EBI 





TFT 


M 


This IE can contain both uplink and downlink packet filters 
to be sent to the UE or the TWAN/ePDG. 


Bearer TFT 





S1-U SGW F-TEID 


C 


This IE shall be sent on the S1 1 interface if the S1 -U 
interface is used. 


F-TEID 





S5/8-U PQW F-TEID 


C 


This IE shall be sent on the S4, S5/S8 and S1 1 interfaces 
for GTP-based S5/S8 interface. The IVIME/SGSN shall 
ignore the IE on S1 1/S4 for PMIP-based S5/S8 interface. 


F-TEID 


1 


S12SGW F-TEID 


C 


This IE shall be sent on the S4 interface if the S12 
interface is used. 


F-TEID 


2 


S4-U SGW F-TEID 


C 


This IE shall be sent on the S4 interface if the S4-U 

interface is used. 


F-TEID 


3 


S2b-U PGW F-TEID 


c 


This IE (for user plane) shall be sent on the S2b interface. 


F-TEID 


4 


S2a-U PGW F-TEID 


c 


This IE (for user plane) shall be sent on the S2a interface. 


F-TEID 


5 


Bearer Level QoS 


M 




Bearer QoS 





Charging Id 


c 


This IE shall be sent on the S5/S8 interface. 


Charging Id 








If the S5/S8 interface is GTP, this IE may be sent on the 
S4 interface, in order to support CAMEL charging at the 
SGSN. 


CO 


This IE shall be sent on the S2a/S2b interface. 


Bearer Flags 





Applicable flags are: 

PPC (Prohibit Payload Compression) : this flag 
may be set on the S5/S8 and S4/S1 1 interfaces. 

vSRVCC indicator: This IE may be included by the 
PGW on the S5/S8 interface according to 3GPP 
TS 23.216 [43]. When received from S5/S8, SGW 
shall forward on the S1 1 interface. 


Bearer Flags 





Protocol 

Configuration Options 
(PCO) 





This IE may be sent on the S5/S8 and S4/S1 1 interfaces. 
This bearer level IE takes precedence over the PCO IE in 
the message body if they both exist. 


PCO 






7.2.4 Create Bearer Response 

The Create Bearer Response message shall be sent on the S5/S8 interface by the SGW to the PGW, and on the SI 1 
interface by the MME to the SGW as part of the Dedicated Bearer Activation procedure. 

The message shall also be sent on the S5/S8 interface by the SGW to the PGW and on the S4 interface by the SGSN to 
the SGW as part of Secondary PDP Context Activation procedure or the Network Requested Secondary PDP Context 
Activation procedure. 

The message shall also be sent on the S2a interface by the TWAN to the PGW as part of the Dedicated bearer activation 
in WLAN on GTP S2a and on the S2b interface by the ePDG to the PGW as part of the Dedicated S2b bearer activation 
with GTP on S2b. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 
"Request accepted". 
"Request accepted partially". 
- "Context not found". 

"Semantic error in the TFT operation" . 
"Syntactic error in the TFT operation" . 
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"Semantic errors in packet filter(s)". 
"Syntactic errors in packet filter(s)". 

- "Unable to page UE". 
"UE not responding" . 

"Unable to page UE due to Suspension". 

- "UE refuses". 

- "Denied in RAT". 



Table 7.2.4-1 : Information Elements in a Create Bearer Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


Cause 


M 




Cause 





Bearer Contexts 


M 


Several IBs with this type and instance value shall be 
included on the S4/S1 1 , S5/S8 and S2a/S2b interfaces as 
necessary to represent a list of Bearers. 


Bearer Context 





Recovery 


C 


This IE shall be included on the b4/S1 1 , S5/S8 and 
S2a/S2b interfaces if contacting the peer for the first time 


Recovery 





MME-FQ-CSID 


C 


This IE shall be included by the MME on the S1 1 
interfaceand shall be forwarded by the SGW on the S5/S8 
interfaces according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 





SQW-FQ-CSID 


C 


This IE shall be included by the SGiW on the bo/faS 
interfaces according to the requirements in 3GPP TS 
oo nn7 n 7i 


FQ-CSID 


1 


ePDG-FQ-CSID 


c 


This IE shall be included by the ePDG on the S2b interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


2 


TWAN-FQ-CSID 


c 


This IE shall be included by the TWAN on the S2a 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 


3 


Protocol 

Configuration Options 
(PCO) 


c 


If the UE includes the PCO IE, then the MME/SGSN shall 
copy the content of this IE transparently from the PCO IE 
included by the UE. If the SGW receives PCO from 
MME/SGSN, SGW shall forward it to the PGW. 


PCO 





UE Time Zone 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


UE Time Zone 





CO 


The SGW shall f onward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


User Location 
Information (ULi) 


CO 


This IE shall be included by the MME on the S1 1 interface 
or by the SGSN on the S4 interface. The CGI/SAI shall be 
included by SGSN and the ECGI shall be included by 
MME. 


ULI 





CO 


The SGW shall forward this IE on the S5/S8 interface if it 
receives it from the MME/SGSN. 


Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


VS 
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Table 7.2.4-2: Bearer Context within Create Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Uctets and o 




OMeM. 


^^^^^^^l^pare and.lnstanc^^^^^^^^^^^^^^^^^^K 


Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 








EPb Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, it gives information on the reason. 


Cause 





S1-U eNodeB F-TEID 


C 


This IE shall be sent on the S1 1 interface if the S1 -U 
interface is used. 


F-TEID 





S1-U SGW F-TEID 


C 


This IE shall be sent on the S1 1 interface. It shall be used 
to correlate the bearers with those in the Create Bearer 
Request. 


F-TEID 


1 


S5/8-U SGW F-TEID 


C 


This IE shall be sent on the S5/S8 interfaces. 


F-TEID 


2 


S5/8-U PGW F-TEID 


C 


This IE shall be sent on the S5/S8 interfaces. It shall be 
used to correlate the bearers with those in the Create 

Bearer Request. 


F-TEID 


3 


S12RNC F-TEID 


C 


This IE shall be sent on the S4 interface if the S12 
interface is used. See N0TE1 . 


F-TEID 


4 


S12 SGW F-TEID 


C 


This IE shall be sent on the S4 interface. It shall be used to 
correlate the bearers with those in the Create Bearer 
Request. See N0TE1 . 


F-TEID 


5 


II ^^^r^ki F" 1 i~v 

S4-U SGSN F-TEID 


c 


This IE shall be sent on the S4 interface if the S4-U 
interface is used. See N0TE1 . 


F-TEID 


6 


S4-U SGW F-TEID 


c 


This IE shall be sent on the S4 interface. It shall be used to 

correlate the bearers with those in the Create Bearer 
Request. See N0TE1. 


F-TEID 


7 


S2b-U ePDG F-TEID 


c 


This IE shall be sent on the S2b interface. 


F-TEID 


8 


S2b-U PGW F-TEID 


c 


This IE shall be sent on the S2b interface. It shall be used 
to correlate the bearers with those in the Create Bearer 
Request. 


F-TEID 


9 


S2a-U TWAN F-TEID 


c 


This IE shall be sent on the S2a interface. 


F-TEID 


10 


S2a-U PGW F-TEID 


c 


This IE shall be sent on the S2a interface. It shall be used 
to correlate the bearers with those in the Create Bearer 
Request. 


F-TEID 


11 


Protocol 


CO 


If the UE includes the PCO IE in the corresponding 


PCO 





Configuration Options 
(PCO) 




message, then the MME/SGSN shall copy the content of 
this IE transparently from the PCO IE included by the UE. 
If the SGW receives PCO from MME/SGSN, SGW shall 
forward it to the PGW. This bearer level IE takes 
precedence over the PCO IE in the message body if they 
both exist. 






NOTE 1 : When sending a Create Bearer Request message to an S4-SGSN for a UE in idle mode, the SGW 
can not know whether the S4-SGSN will establish a direct user plane tunnel between the RNC and 


the SGW. The SGW may include either the S4-U SGW F-TEID IE or the S12 SGW F-TEID IE in the 


Create Bearer Request message. The S4-SGSN will decide whether to establish a direct user plane 


tunnel or not and will provide accordingly either a 812 RNC F-TEID or a S4-U SGSN F-TEID in the 


Create Bearer Response message, where the interface type of the provided F-TEID may differ from 
the interface type of the SGW F-TEID used for bearer correlation, e.g. if the SGW includes the S4-U 


SGW F-TEID in the Create Bearer Request message, and if the SGSN decides to use Direct 
Tunnelling, the S4-SGSN shall provide the S12 RNC F-TEID in the Create Bearer Response 
message, together with S4-U SGW F-TEID. The SGW should not treat this as an error. 





7.2.5 Bearer Resource Command 

A Bearer Resource Command message shall be sent from a MME to a SGW and forwarded to PGW as a part of the UE 

requested bearer resource allocation procedure or UE requested bearer resource modification procedure (which is used 
also for a dedicated bearer deactivation) , as specified by 3GPP TS 24.301 [23]. 

The message shall also be sent on the S4 interface by a SGSN to a SGW and on the S5/S8 interface by a SGW to a 
PGW as part of the MS initiated PDP Context modification procedure, or secondary PDP context activation procedure. 

Table 7.2.5-1 specifies the presence of the lEs in the message. 
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Table 7.2.5-1 : Information Elements in a Bearer Resource Command 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


Linked EPS Bearer ID 
(LBI) 


M 




EBI 





Procedure 

Transaction Id (PTI) 


M 




PTI 





Flow Quality of 
Service (Flow QoS) 


C 


This IE shall be included on the S4/S1 1 interface if the 
"Requested New QoS"/"Required OoS" is included in the 
corresponding NAS message (see section 9.5.10 and 
section 9.5.15a in 3GPP TS 24.008 [5]) or the "Required 
traffic flow QoS" is included in the corresponding NAS 
message (see section 8.3.8 and section 8.3.10 in 3GPP 
TS 24.301 [23]). 

If SGW receives this IE, SGW shall forward it to PGW 
across S5/S8 interface. 


Flow QoS 





Traffic Aggregate 
Description (TAD) 


M 


The TAD consists of the description of the pacl<et filter(s) 

for a traffic flow aggregate. 

MME shall include this IE over S1 1 interface. 






CO 


t£ A ^\ K 1 xl ■ 1 l~~ X X 1 II l~~ 'X 1 II' 1 1 'X 

If S4-SGSN receives this IE from the UE, it shall include it 
over S4 interface. 


TAD 







CO 


If SGW receives this IE, the SGW shall forward it to PGW 
over S5/S8 interface. See NOTE 2. 






RAT Type 


c 


This IE shall be included for MS initiated PDP Context 
modification procedure and Secondary PDP context 
activation procedure. 


RAT Type 





Serving Networl< 





This IE may be included in the MS initiated PDP Context 
modification procedure. 


Serving Network 





User Location 
Information (ULi) 





This IE may be included in the MS initiated PDP Context 
modification procedure. 


ULI 





EPS Bearer ID 


c 


This IE indicates the EPS Bearer that needs to be 
modified. It shall be included for MS initiated PDP Context 
modification procedure. For EUTRAN this IE shall be 
present if it is triggered by the NAS Bearer Resource 
Modification Request message and its value shall be set to 
the value of the "EPS bearer identity for packet filter" IE 
received in that NAS message. 


EBI 


1 


Indication Flags 





This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Change Reporting Support Indication: this flag 
may be included in the MS initiated PDP Context 
modification procedure. 

Direct Tunnel Flag: this flag may be included in the 
MS initiated PDP Context Modification procedure. 


Indication 





S4-U SGSN F-TEID 


c 


This IE shall be included on the S4 interface when direct 
tunnel is not established in the MS initiated PDP Context 
modification procedure See NOTE 1 


F-TEID 





S12 RNC F-TEID 


c 


This IE shall be included on the S4 interface when direct 
tunnel flag is set to 1 in the MS initiated PDP Context 
modification procedure. See NOTE 1 


F-TEID 


1 


Protocol 

Configuration Options 
(PCO) 







PCO 





Signalling Priority 
Indication 


CO 


The SGSN/MME shall include this IE on the S4/S1 1 
interface if the UE indicates low access priority during the 
procedure. 

The SGW shall forward this IE on the S5/S8 interfaces if 
received from the MME/SGSN. 


Signalling Priority 
Indication 





Private Extension 







Private Extension 


vs 


NOTE 1: The conditional S4-U SGSN F-TEID and S12 RNC F-TEID IE are redundant (as the lEs will be 
included in Update Bearer Response message in the MS initiated PDP Context modification 
procedure). The receiver may ignore it. 

NOTE 2: In the secondary PDP context activation procedure, if the Bearer Resource Command message 

without TAD IE is received, the PGW shall reject the message with cause "UE context without TFT 
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I already activated". | 

NOTE: Depending on the protocol type on the S5/S8 interface, the SOW or the PGW will determine if the UE is 
requesting an Allocation/Modification operation of bearer resources for a traffic flow aggregate based on 
the TFT operation code and the packet filter ID value in the Traffic Aggregate (TAD) IE and/or the 
presence of the EPS Bearer ID IE. 

7.2.6 Bearer Resource Failure Indication 

A Bearer Resource Failure Indication shall be sent by the PGW to an SOW and forwarded to the MME to indicate 
failure of the UE requested bearer resource allocation procedure or UE requested bearer resource modification 
procedure, as specified by 3GPP TS 24.301 [23]. 

The message shall also be sent by a PGW to an SGW and forwarded to an SGSN as part of the failure of an MS 
initiated PDP Context modification procedure or secondary PDP context activation procedure. 

Table 7.2.6-1 specifies the presence of the lEs in the message. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Semantic error in the TAD operation". 

"Syntactic error in the TAD operation". 

" Semantic errors in packet filter(s) " . 

" Syntactic errors in packet filter(s) " . 

"Collision with network initiated request". 

"Service denied". 
"Bearer handUng not supported". 
"UE context without TFT already activated". 



Table 7.2.6-1 : Information Elements in a Bearer Resource Failure Indication 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










Cause 


M 




Cause 





Linked EPS Bearer ID 


M 


See subclause 6.1 .1 "Presence requirements of 
Information Elements". 


EBI 





Procedure 
Transaction ID (PTI) 


M 


See subclause 6.1 .1 "Presence requirements of 
Information Elements". 


PTI 





Recovery 







Recovery 





Private Extension 







Private Extension 


vs 



7.2.7 Modify Bearer Request 

The direction of this message shall be from MME/S4-SGSN to SGW and/or from SGW to PGW (see Table 6.1-1). 

The Modify Bearer Request message shall only be sent on the SI 1 interface by the MME to the SGW and on the S5/S8 
interfaces by the SGW to the PGW as part of the procedures: 

- E-UTRAN Tracking Area Update without SGW Change 

- UE triggered Service Request 

- S 1 -based Handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 
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- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN Initial Attach 

- UE requested PDN connectivity 

- 3G SGSN to MME combined hard handover and SRNS relocation procedure 
X2-based handover without SGW relocation 

- UTRAN/GERAN to E-UTRAN SRVCC 

It shall also only be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interfaces by the SGW to the 
PGW as part of the procedures: 

Routeing Area Update with MME interaction and without SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs without 

SGW change 

- lu mode RA Update Procedure without SGW change 

- Serving RNS Relocation Procedure 

- Combined Hard Handover and SRNS Relocation Procedure 

- Combined Cell / URA Update and SRNS Relocation Procedure 

- Enhanced Serving RNS Relocation without SGW relocation 

- UE Initiated Service Request Procedure 

- lu mode to A/Gb mode Intra SGSN Change 
A/Gb mode to lu mode Intra SGSN Change 

- lu mode to A/Gb mode Inter-SGSN Change 

- A/Gb mode to lu mode Inter-SGSN Change 

- Paging Response with no established user plane on S4 

- PDP Context Activation Procedure 

- UTRAN/GERAN to UTRAN (HSPA) SRVCC 

only on the S4 interface by the SGSN to the SGW as part of the procedures: 
RAB Assignment Procedure 

- SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support procedures and SRVCC from UTRAN 
(HSPA) to UTRAN or GERAN wdth DTM HO support. 

and only on the S5/S8 interfaces by the SGW to the PGW as part of the procedures: 

- Tracking Area Update procedure with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 

- X2 based handover with SGW relocation 

- Gn/Gp SGSN to MME Tracking Area Update 

- Enhanced Serving RNS Relocation with SGW relocation 
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- Routeing Area Update with MME interaction and with SGW change 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update using S4 with SGW 
change 

- lu mode RA Update Procedure using S4 with SGW change 

Restoration of PDN connections after an SGW failure if the MME/SGSN and PGW support these procedures as 

specified in 3GPP TS 23.007 [17] 

and on the S2b interface by the ePDG to the PGW as part of the procedures: 

UE initiated IPsec tunnel update procedure 

If the optional network triggered service restoration feature is supported by the MME, SGSN and SGW, then the 
Modify Bearer Request message shall also be sent as part of the network triggered service restoration procedure with 
ISR during an intra MME TAU and an intra S4-SGSN RAU procedure for UEs that had ISR active before either the 
MME or the S4-SGSN has restarted, as specified in 3GPP TS 23.007 [17]: 

- on the S 1 1 interface by the MME to the SGW, if the MME detected that the ISR associated S4-SGSN has 
restarted and UE performs a TAU procedure; 

- on the S4 interface by the S4-SGSN to the SGW, if the S4-SGSN detected that the ISR associated MME has 

restarted and UE performs a RAU procedure. 

This message can be used as an implicit resume of the suspended bearers in the SGW and in the PGW (see 3GPP TS 
23.216 [43] sections 6.2.2.1 and 6.3.2.1, 3GPP TS 23.272 [21] sections 6.3, 6.5 and 7.4). A Modify Bearer Request used 
as an implicit resume can contain zero or more IE(s), depending on the conditions of presence of the lEs specified in 
table 7.2.7-1. The PGW should not consider a Modify Bearer Request with zero IE as an error. 

The Modify Bearer Request message may also be sent in the following cases from the S4-SGSN to the SGW/PGW to 
report a change of Serving Network, User CSG Information or/and UE Time Zone which occured during a previous 
RAU procedure without SGSN change but which has not been reported yet to the SGW/PGW: 

- during a Service Request to establish data radio bearers for the corresponding PDP context for a UE in UTRAN 
with an existing S4-U tunnel; 

- when the SGSN receives an uplink PDU from a UE in GERAN with an existing S4-U tunnel. 
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Table 7.2.7-1 : Information Elements in a Modify Bearer Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


ME Identity (I^EI) 


C 


If an SOW receives this IE from an MME/SGSN during a 
TAU/RAU/Handover procedure, the SGW shall fonward it 
across the S5/S8 interface to the PGW. 


MEI 





User Location 
Information (ULI) 


C 


The MME/SGSN shall include this IE for the 
TAU/RAU/Handover procedures if the PGW/PCRF has 
requested location information change reporting and 
MME/SGSN support location information change reporting. 
An MME/SGSN which supports location information 
change shall include this IE for UE-initiated Service 
Request procedure if the PGW/PCRF has requested 
location information change reporting and the UE"s 
location info has changed. See NOTE 5. 
When ISR is active, the MME/SGSN which supports 
location information change shall include this IE for UE- 
initiated Service Request procedure, if the PGW/PCRF has 
requested location information change reporting. 

When ISR is not active, the SGW shall include this IE on 
S5/S8 if it receives the ULI from MME/SGSN. 
When ISR is active, the SGW shall include this IE on 
S5/S8 If 

- it receives the ULI from MME/S4-SGSN and the 
RAT Type has changed since last reported; or 

- it receives the ULI from MME/S4-SGSN and the 
CLII flag has been set to 1 . 


ULI 







CO 


This IE shall also be included on the S4/S1 1 interface for a 
TAU/RAU/Handover with MME/SGSN change without 
SGW change procedure, if the level of support (User 
Location Change Reporting and/or CSG Information 
Change Reporting) changes the MME shall include the 
ECGI and /or TAI in the ULI, the SGSN shall include either 
the CGI or SAI or RAI, or CGI/SAI together with RAI in the 
ULI. See NOTE 10. 

The SGW shall include this IE on S5/S8 if it receives the 
ULI from MME/SGSN. 










\ nis It snail ue inciuoeu on oi i/o4 inierrace ouring me 

following procedures: 

- TAU/RAU/handover if Serving Network is changed. 

- TAU/RAU when the UE was ISR activated which is 
indicated by ISRAU flag. 

- UE triggered Service Request when UE is ISR 
activated. 






Serving Networl< 




- UE initiated Service Request if ISR is not active, but 
the Serving Network has changed during previous 
mobility procedures, i.e. intra MME/S4-SGSN 
TAU/RAU and the change has not been reported to 
the PGW yet. 

- TAU/RAU procedure as part of the optional network 

triggered service restoration procedure with ISR, as 
specified by 3GPP TS 23.007 [17]. 


Serving Network 







CO 


This IE shall also be included on the S4/S1 1 interface 
during a TAU/RAU/Handover with MME/SGSN change if 
the source MME/SGSN has set the SNCR bit in the 
Change to Report Flags IE in the Forward Relocation 
Request or Context Response message. 








CO 


This IE shall be included on S5/S8 if the SGW receives this 

IE from MME/SGSN and if ISR is not active. 

This IE shall be included on S5/S8 if the SGW receives this 
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IE from MME/SGSN and ISR is active and the Modify 
Bearer Request message needs to be sent to the PGW as 
specified in the 3GPP TS 23.401 [3]. 






RAT Type 


C 


This IE shall be sent on the S1 1 interface for a TAU with 
an SGSN interaction, UE triggered Service Request or an 
l-RAT Handover. 

This IE shall be sent on the S4 interface for a RAU with 

MIVIE interaction, a RAU with an SGSN change, a UE 

Initiated Service Request or an l-RAT Handover. 

This IE shall be sent on the S5/S8 interface if the RAT type 

changes. 


RAT Type 





CO 


If SGW receives this IE from MME/SGSN during a 
TAU/RAU/Handover with SGW change procedure, the 
SGW shall fonward it across S5/S8 interface to PGW. See 
NOTE 10. 


CO 


The IE shall be sent on the SI 1/S4 interface during the 
following procedures: 

- an inter MME TAU or inter SGSN RAU when UE 
was ISR activated which is indicated by ISRAU flag. 

- TAU/RAU procedure as part of optional network 
triggered service restoration procedure with ISR, as 
specified by 3GPP TS 23.007 [17]. 

If ISR is active, this IE shall also be included on the S1 1 
interface in the S1-U GTP-U tunnel setup procedure during 
an intra-MME intra-SGW TAU procedure. 


Indication Flags 


C 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags are: 

ISRAI: This flag shall be used on S4/S1 1 interface 
and set to 1 if the ISR is established between the 
MME and the S4 SGSN. 

Handover Indication: This flag shall be set to 1 on 

the S4/S1 1 and S5/S8 interfaces during an E- 
UTRAN Initial Attach or for a UE Requested PDN 
Connectivity or a PDP Context Activation 
procedure, if the PDN connection/PDP context is 
handed-over from non-3GPP access. 

Direct Tunnel Flag: This flag shall be used on the 
S4 interface and set to 1 if Direct Tunnel is used. 

Change Reporting support Indication: shall be 
used on S4/S1 1 , S5/S8 and set if the SGSN/MME 
supports location Info Change Reporting and if the 
SGSN/MME's operator policy permits reporting of 
location change to the operator of the PGW with 
which the session is established. This flag should 
be ignored by SGW if no message is sent on 
S5/S8. See NOTE 4. 

CSG Change Reporting Support Indication: shall 
be used on S4/S1 1 , S5/S8 and set if the 
SGSN/MME supports CSG Information Change 
Reporting and if the SGSN/MME's operator policy 
permits reporting of the CSG Information change 
to the operator of the PGW with which the session 
is established. This flag shall be ignored by SGW if 
no message is sent on S5/S8. See NOTE 4. 

Change F-TEID support Indication: This flag shall 
be used on S4/S1 1 for an IDLE state UE initiated 
TAU/RAU procedure and set to 1 to allow the 
SGW changing the GTP-U F-TEID. 

Propagate BBAI Information Change: 

The MME/SGSN shall set this flag on S1 1/S4 in 


Indication 
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procedures without MME/SGSN change if the 
PGW has requested H{e)NB information reporting 
and the H(e)NB local IP address or UDP port 
number information from H(e)NB in UE associated 
S1/lu signalling has changed. 
(NOTE 8) 

The MME/SGSN shall set this flag on S1 1/S4 
during TAU/RAU/Handover with MME/SGSN 
change procedures if the PGW has requested 
H(e)NB information reporting. 
See 3GPPTS 23.139 [51]. 

- CS to PS SRVCG indication: This flag shall be 
used on S4/S1 1 and on S5/S8, and it shall be set 
during UTRAN/GERAN to E-UTRAN/UTRAN 
(HSPA) SRVCG procedure as specified in 3GPP 
TS 23.216 [43]. 

Change of Location Information Indication (GUI): 
This flag shall be used on S4/S1 1 interface only 
when the ISR is active for the UE. This flag shall 
be set to 1 by the MME/S4-SGSN if the ULI IE is 
included in the Modify Bearer Request message 
and the location information has changed since 
last reported by the MME/S4-SGSN. See NOTE 9. 
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Sender F-TEID for 
Control Plane 


C 


The new MME/SGSN shall include this IE on the S1 1 and 
S4 interfaces for a TAU/RAU/ Handover with an 
MME/SGSN change and without any SGW change. See 
NOTE 10. 

If the SGW receives this IE and if it finds that its value is 
the same as the earlier received value of this IE for this 
UE, it should interpret this to mean that the MME/SGSN 
has not changed. 

The new SGW shall include this IE on the S5 and S8 
interfaces for a TAU/RAU/Handover with a SGW change. 
See NOTE 10. 

If the PGW receives this IE and if it finds that its value is 
the same as the earlier received value of this IE for this 
PDN connection, it should Interpret this to mean that the 
SGW has not changed. 


F-TEID 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


C 


The APN-AMBR shall be sent for the PS mobility from the 
Gn/Gp SGSN to the S4 SGSN/MME procedures.. 


AMBR 





Delay Downlink 
Packet Notification 


C 


This IE shall be sent on the S1 1 interface for a UE 

triggered Service Request. 


Delay Value 





Request 


CO 


This IE shall be sent on the S4 interface for a UE triggered 
Service Request. 






Bearer Contexts to be 
modified 


C 


This IE shall be sent on the S4/S1 1 interface and S5/S8 
interface, except 

on the S5/S8 interface for a UE triggered Service 

Request. 

on the S5/S8 interface for a TAU/RAU/HO without 
SGW change procedure. See NOTE 10. 
(see NOTE 6). 

When Handover Indication flag is set to 1 (i.e., for 
EUTRAN Initial Attach or UE Requested PDN Connectivity 
when the UE comes from non-3GPP access), the PGW 
shall ignore this IE. See NOTE 1. 

Several lEs with the same type and instance value may be 
included as necessary to represent a list of Bearers to be 
modified. 

During a TAU/RAU/Handover procedure with an SGW 
change, the SGW includes all bearers it received from the 
MME/SGSN (Bearer Contexts to be created, or Bearer 
Contexts to be modified and also Bearer Contexts to be 

removed) into the list of 'Bearer Contexts to be modified' 
lEs, which are then sent on the S5/S8 interface to the 
PGW (see NOTE 2, see NOTE 10). 


Bearer Context 





Bearer Contexts to be 
removed 


C 


This IE shall be included on the S4 and S1 1 interfaces for 
the TAU/RAU/Handover and Service Request procedures 

where any of the bearers existing before the 
TAU/RAU/Handover procedure and Service Request 
procedures will be deactivated as consequence of the 
TAU/RAU/Handover procedure and Service Request 
procedures, (see NOTE 3) 

For each of those bearers, an IE with the same type and 
instance value, shall be included. 


Bearer Context 


1 


Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





UE Time Zone 


CO 


This IE shall be included by the MME/SGSN on the SI 1/S4 
interfaces if the UE Time Zone has changed in the case of 
TAU/RAU/Handover or UE initiated Service Request 
procedure. See NOTE 5. 


UE Time Zone 







CO 


This IE shall also be included on the S4/S1 1 interface 
during a TAU/RAU/Handover with MME/SGSN change if 
the source MME/SGSN has set the TZCR bit in the 
Change to Report Flags IE in the Forward Relocation 
Request or Context Response message. 








C 


If SGW receives this IE, SGW shall forward it to PGW 

across S5/S8 interface. 






MME-FQ-CSID 


C 


This IE shall be included by MME on S1 1 and shall be 
forwarded by SGW on S5/S8 according to the 
requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 
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SGW-FQ-CSID 





Tflis IE shall be included by SGW on S5/S8 according to 
the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


UserCSG 
Information (UCI) 


CO 


The MME/SGSN shall include this IE for Handover 
procedures and UE-initiated Service Request procedure if 
the PGW/PCRF has requested CSG Info reporting and the 
IVIME/SGSN support the CSG information reporting and 
the User CSG information has changed. 
In TAU/RAU procedure without SGW change, this IE shall 
also be sent if the PGW/PCRF has requested CSG info 
reporting and IVIME support CSG info reporting and the 
User CSG information has changed when UE requested to 
active E-RAB for all the active EPS bearers in TAU 
procedure or to keep the lu connection after the completion 
of the RAU procedure. See NOTE 5. See NOTE 10. 
The SGW shall include this IE on S5/S8 if it receives the 
User CSG Information from MME/SGSN. 


UCI 





UE Local IP Address 


GO 


If the UE local IP Address has changed, the ePDG shall 
include this IE on S2b interface based on local policy for 
Fixed Broadband access network interworking (see 3GPP 
TS 23.139 [51]). 


IP Address 


1 


UE UDP Port 


CO 


The ePDG shall include this IE on S2b interface if NAT is 
detected and UE Local IP Address is present for Fixed 
Broadband access network interworking (see 3GPP TS 
23.139 [51]). 


Port Number 


1 


MME/S4-SGSN LDN 





This IE is optionally sent by the MME to the SGW on the 
S1 1 interface and by the SGSN to the SGW on the S4 

interface (see 3GPP TS 32.423 [44]), when communicating 
the LDN to the peer node for the first time. 


Local 
Distinguished 
Name (LDN) 





SOW LDN 





This IE is optionally sent by the SGW to the PGW on the 
S5/S8 interfaces (see 3GPP TS 32.423 [44]), for inter- 
SGW mobity, when communicating the LDN to the peer 
node for the first time. 


Local 
Distinguished 
Name (LDN) 


1 


H(e)NB Local IP 
Address 


CO 


The MME/SGSN shall include this IE on SI 1/S4 interface if 
the PGW/PCRF has requested H(e)NB information 
reporting and the MME/SGSN has received this 
information from H(e)NB in UE associated Sl/lu signalling 
(see 3GPPTS 23.139 [51]). 

The SGW shall forward this IE on S5/S8 interface if it is 

received from the MME/SGSN and 

the Modify Bearer Request message needs to be 
sent to the PGW as specified in the 3GPP TS 
23.401 [3]; or 

the Propagate BBAI information change flag is 
received from the MME/SGSN. 

(NOTE 7) 


IP Address 





H(e)NB UDP Port 


CO 


The MME/SGSN shall include this IE on SI 1/S4 interface if 
the PGW/PCRF has requested H(e)NB information 
reporting and the MME/SGSN has received this 
information from H(e)NB in UE associated Sl/lu signalling 
(see 3GPPTS 23.139 [51]). 

The SGW shall forward this IE on S5/S8 interface if it is 

received from the MME/SGSN and 

the Modify Bearer Request message needs to be 
sent to the PGW as specified in the 3GPP TS 
23.401 [3]; or 

the Propagate BBAI information change flag is 
received from the MME/SGSN. 

(NOTE 7) 


Port Number 





MME/S4-SGSN 
Identifier 


CO 


If the PGW triggered SGW restoration procedure is 
supported, the MME/S4-SGSN shall include this IE on 

SI 1/S4 interface and the SGW shall forward this IE on S5 
interface in the existing signalling as specified in 3GPP TS 
23.007 [17]. 


IP Address 


2 


Private Extension 







Private Extension 


VS 
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N0TE1 : This requirement is introduced for bacl<wards compatibility reasons. If Bearer Contexts to be modified 
IE(s) is received in the Modify Bearer Request message, the PGW shall include corresponding 
Bearer Contexts modified IE(s) in the Modify Bearer Response message. 

N0TE2: According to the description in 3GPP TS 23.401 [3] e.g. subclause 5.3.3.1 "Tracking Area Update 
procedure with Serving GW change" and 3GPP TS 23.060 [35], during a TAU/RAU/Handover 
procedure with an SGW change, if the SGW receives 'Bearer Context to be removed' lEs, the SGW 
shall allocate the S5/8-U SGW F-TEID for those bearers and include also these bearers in the 
'Bearer contexts to be modified' IE, which is then sent within this message on the S5/S8 interface to 
the PGW. 

NOTES: The 'Bearer Contexts to be removed' IE signals to the SGW that these bearers will be removed by 
the MME/SGSN later on by separate procedures (e.g. MME/S4-SGSN initiated Dedicated Bearer 
Deactivation procedure). Therefore, the SGW will not delete these bearers during the ongoing 
TAU/RAU/Handover procedure (without an SGW change), a Handover procedure (with an SGW 
change except for an X2-Handover) and a Service Request procedure. 

NOTE 4: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1) 

defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In 
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change 
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change 
Reporting Support Indication. 

NOTE 5: In TAU/RAU procedure, if the UE requested to active E-RAB for all the active EPS bearers in TAU 

procedure or to keep the lu connection after the completion of the RAU procedure, the User Location 
Info/User CSG Information/UE Time Zone shall not be sent in S1-U GTP-U tunnel setup procedure 
during the TAU procedure (see 3GPP TS 24.301 [23]) or in the Service Request procedure after the 
completion of the RAU procedure. 

NOTE 6: 3GPP TS 23.401 [3] specifies that the MME/SGSN shall send the Modify Bearer Request message 
to the SGW in the SI based handover/ Inter RAT handover for an unaccepted PDN Connection 
when at least one PDN Connection of the UE was accepted by the RAN. In this case, the MME shall 
indicate the reserved IP address to the SGW in the SI eNodeB F-TEID and the SGSN shall indicate 
the reserved IP address to the SGW in the SI 2 RNC F-TEID for at least all the non GBR bearers in 
the unaccepted PDN Connection in the Bearer Context to be modified IE. An implementation may 
provide the mentioned reserved IP address e.g. from one of the reserved IP address ranges (see 
RFC5735 or http://www.iana.net/assiqnments/ipv4-address-space/ipv4-address-space.xml ), or the IP 
address may be provisioned by a configuration. 

NOTE 7: This IE is sent on SI 1/S4 in the specified conditions regardless of whether the H(e)NB local IP 

address and UDP port number information has changed or not to enable the SGW to propagate this 
IE in Modify Bearer Request over S5/S8 when required for reasons other than reporting a change in 
the H(e)NB local IP address and UDP port number information. 

NOTE 8: H(e)NB local IP address and UDP port number information changes when the UE moves from an 
(e)NB to an H(e)NB, or from one H(e)NB to another H(e)NB with a change in the fixed network 
backhaul, or from one H(e)NB to a (e)NB. 

The SGW shall send a Modify Bearer Request on S5/S8 if any of the following condition is met: 

a) the Propagate BBAI Information Change flag is received from the MME/SGSN; 

b) ISR is active and the RAT type has changed. 

NOTE 9: When ISR is active, the CLII flag allows the SGW to avoid sending Modify Bearer Request message 
over S5/S8 interface during UE-initiated Service Request procedure, when the ULI IE is included 
over SI 1/S4 Modify Bearer Request message but the location information and the RAT Type has not 
changed since last reported by the SGW. 

NOTE 10: The RAU/TAU/Handover procedure which requires an SGW selection for the first time, e.g. a Gn/Gp 
SGSN to an S4 SGSN/MME RAU/TAU/Handover procedure, shall be handled in a similar manner to 

the RAU/TAU/Handover with an SGW change procedure. 
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Table 7.2.7-2: Bearer Context to be modified within lUlodify Bearer Request 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


^^^^^^^^^^ = n 


Ctetete* 


■l^^^^^^^^pare Instancj^^^^^^^^^^^^^^^^^^ft 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





S1 eNodeB F-TEID 


C 


This IE shall be sent on the S1 1 interface If the S1 -U is 
being used: 

for an eUTRAN initial attach 

a UE triggered Service Request 

In all S1 -U GTP-U tunnel setup procedure during a 
TAU procedure (see 3GPP TS 24.301 [23]) 
/handover cases. 

If an MME Is aware that the eNodeB supports both IP 
address types, the MME shall send both IP addresses 
within an F-TEID IE. If only one IP address is included, 
then the SGW shall assume that the eNodeB does not 
support the other IP address type. 


F-TEID 





S5/8-U SGW F-TEID 


C 


This IE shall be sent on the S5/S8 Interfaces for a 
Handover or a TAU/RAU with a SGW change. 


F-TEID 


1 


S12 RNC F-TEID 


c 


If available, this IE shall be included if the message is sent 
on the S4 interface if S12 interface is being used. If an S4- 
SGSN is aware that the RNC supports both IP address 
types, the S4-SGSN shall send both IP addresses within 
an F-TEID IE. If only one IP address Is included, then the 
SGW shall assume that the RNC does not support the 
other IP address type. 


F-TEID 


2 


S4-U SGSN F-TEID 


c 


If available, this IE shall be included if the message is sent 

on the S4 Interface, if S4-U is being used. If an S4-SGSN 
supports both IP address types, the S4-SGSN shall send 
both IP addresses within an F-TEID IE. If only one IP 
address Is Included, then the SGW shall assume that the 
S4-SGSN does not support the other IP address type. 


F-TEID 


3 


NOTE 1 : If only EPS Bearer ID IE is included in the Bearer Context to be modified IE during the TAU/RAU 
without SGW change procedure, the SGW shall remove the stored SGSN/RNC/eNodeB userplane 
F-TEID locally. 


Table 7.2.7-3: Bearer Context to be removed within lUlodify Bearer Request 


Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


^^^^^^^^^ n 


Octets 4 


I^^^^^^^K Spare Instano^^^^^^^^^^^^^^^^^^H 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 






7.2.8 Modify Bearer Response 

The Modify Bearer Response message shall be sent on the SI 1 interface by the SGW to the MME and on the S5/S8 
interfaces by the PGW to the SGW as part of the procedures: 

- E-UTRAN Tracking Area Update without SGW Change 

- UE triggered Service Request 
SI -based Handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 
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- E-UTRAN Initial Attach 

- UE requested PDN connectivity 

- 3G SGSN to MME combined hard handover and SRNS relocation procedure 

- X2-based handover without SGW relocation 

It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interfaces by the PGW to the SGW 
as part of the procedures: 

- Routeing Area Update with MME interaction and without SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs without 
SGW change 

- lu mode RA Update Procedure without SGW change 
Serving RNS Relocation Procedure 

- Combined Hard Handover and SRNS Relocation Procedure 

- Combined Cell / URA Update and SRNS Relocation Procedure 

- Enhanced Serving RNS Relocation without SGW relocation 

- UE Initiated Service Request Procedure 

- lu mode to A/Gb mode Intra SGSN Change 

- A/Gb mode to lu mode Intra SGSN Change 

- lu mode to A/Gb mode Inter-SGSN Change 

- A/Gb mode to lu mode Inter-SGSN Change 

- Paging Response with no established user plane on S4 

- PDP Context Activation Procedure 

on the S4 interface by the SGSN to the SGW as part of: 

- RAB Assignment Procedure 

and on the S5/S8 interfaces by the PGW to the SGW as part of: 
Tracking Area Update procedure with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 

- X2 based handover with SGW relocation 

- Gn/Gp SGSN to MME Tracking Area Update 

- Enhanced Serving RNS Relocation with SGW relocation 

- Routeing Area Update with MME interaction and with SGW change 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update using S4 with SGW 
change 

- lu mode RA Update Procedure using S4 with SGW change 

- Restoration of PDN connections after an SGW failure if the MME/S4-SGSN and PGW support these procedures 
as specified in 3GPP TS 23.007 [17] 
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If handling of default bearer fails, then Cause at the message level shall be a failure cause. 
Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially". 
- "Context not found". 

"Service not supported". 
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Table 7.2.8-1 : Information Elements in a Modify Bearer Response 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










Cause 


M 




Cause 





MSISDN 


C 


This IE shall be included on S5/S8 interfaces by the PGW 
if it is stored in its UE context and if this message is 
triggered due to TAU/RAU/HO with SGW relocation. 


MSISDN 





Linked EPS Bearer ID 


C 


This IE shall be sent on S5/S8 when the UE moves from a 
Gn/Gp SGSN to the S4 SGSN or MME to identify the 
default bearer the PGW selects for the PDN Connection. 
This IE shall also be sent by SGW on S1 1 , S4 during 
Gn/Gp SGSN to S4-SGSN/MME HO procedures to identify 
the default bearer the PGW selects for the PDN 
Connection. 


EBI 





Aggregate Maximum 
Bit Rate (APN-AIVIBR) 


C 


This IE shall be included in the PS mobility from Gn/Gp 
SGSN to the S4 SGSN/MME procedures if the received 
APN-AMBR has been modified by the PCRF or the PGW if 
PCRF is not deployed. 


AMBR 





APN Restriction 


C 


This IE denotes the restriction on the combination of types 
of APN for the APN associated with this EPS bearer 
Context. This IE shall be included over S5/S8 interfaces, 
and shall be forwarded over S1 1/S4 interfaces during 
Gn/Gp SGSN to MME/S4-SGSN handover procedures. 
This IE shall also be included on S5/S8 interfaces during 
the Gn/Gp SGSN to S4 SGSN/MME RAU/TAU 
procedures. 

The target MME or SGSN determines the Maximum APN 
Restriction using the APN Restriction. 


APN Restriction 





Protocol 

Configuration Options 
(PCO) 


C 


If SGW receives this IE from PGW on GTP or PMIP based 
S5/S8, the SGW shall forward PCO to MME/S4-SGSN 
during Inter RAT handover from the UTRAN or from the 
GERAN to the E-UTRAN. See NOTE 2. 


PCO 





Bearer Contexts 
modified 


C 


EPS bearers corresponding to Bearer Contexts to be 
modified that were sent in Modify Bearer Request 
message. Several lEs with the same type and instance 
value may be included as necessary to represent a list of 
the Bearers which are modified. 


Bearer Context 





Bearer Contexts 


c 


EPS bearers corresponding to Bearer Contexts to be 


Bearer Context 


1 


marked for removal 




removed sent in the Modify Bearer Request message. 
Shall be included if request message contained Bearer 
Contexts to be removed. 

For each of those bearers an IE with the same type and 
instance value shall be included. 






Change Reporting 
Action 


c 


This IE shall be included with the appropriate Action field If 

the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





CSG Information 


CO 


This IE shall be included with the appropriate Action field if 


CSG Information 





Reporting Action 




the location CSG Info change reporting mechanism is to be 
started or stopped for this subscriber in the SGSN/MME. 


Reporting Action 




H(e)NB Information 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 


H(e)NB 





Reporting 




interfaces with the appropriate Action field if H(e)NB 
information reporting is to be started or stopped for the 
PDN connection in the SGSN/MME. 


Information 
Reporting 




Charging Gateway 
Name 


c 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface during SGW relocation and when the UE moves 
from Gn/Gp SGSN to S4-SGSN/MME. See NOTE 1 . 


FQDN 





Charging Gateway 
Address 


c 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface during SGW relocation and when the UE moves 
from Gn/Gp SGSN to S4-SGSN/MME. See NOTE 1 . 


IP Address 





PGW-FQ-CSID 


c 


This IE shall be included by PGW on S5/S8and shall be 
forwarded by SGW on S1 1 according to the requirements 
in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by SGW on S1 1 according to the 
requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Recovery 


c 


This IE shall be included if contacting the peer for the first 


Recovery 
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time. 






SGW LDN 





This IE is optionally sent by the SGW to the MME/SGSN 
on the S1 1/S4 interfaces (see 3GPP TS 32.423 [44]), 
when communicating the LDN to the peer node for the first 
time. 


Local 
Distinguished 
Name (LDN) 





PGW LDN 





This IE is optionally sent by the PGW to the SGW on the 
S5/S8 interfaces (see 3GPP TS 32.423 [44]), when 
communicating the LDN to the peer node for the first time. 


Local 
Distinguished 

Name 
(LDN)Name 


1 


Indication Flags 


CO 


This IE shall be included if any one of the applicable flags 
is set to 1 . 

Applicable flags are: 

Static IPv4 Address Flag: This flag shall be set to 1 
on the S5/S8 interface in the TAU/RAU/Handover 
with SGW change procedure if the PDP/PDN IPv4 
address is static as specified in 3GPP TS 32.251 
[8]. See NOTE 3. 


Indication 











Static IPv6 Address Flag: This flag shall be set to 1 
on the S5/S8 interface in the TAU/RAU/Handover 
with SGW change procedure if the PDP/PDN IPv6 
address is static as specified in 3GPP TS 32.251 
[8]. See NOTE 3. 






Private Extension 







Private Extension 


VS 


NOTE 1 : 

NOTE 2: 
NOTE 3: 


Both Charging Gateway Name and Charging Gateway Address shall not be included at the same 

time. When both are available, the operator configures a preferred value. 

If MME receives the IE, but no MAS message is sent, IVIME discards the IE. 

Static IPv4/IPv6 Address Flag is used by SGW to provide dynamic IPv4/v6 address flag information 

as specified in 3GPP TS 32.251 [8]. 
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Table 7.2.8-2: Bearer Context modified witliin lUlodify Bearer Response 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


^ = n 


Ctetete* 


■I^^^^^^B^pare and.lnstanc^^^^^^^^^^^^^^^^^^H 


Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 





S1 SGW F-TEID 


C 


This IE shall be used on the S1 1 interface, if the SI 
interface is used. If the 'Change F-TEID support Indication' 
flag was set to 1 in the Modify Bearer Request and the 
SGW needs to change the F-TEID, the SGW shall include 
the new GTP-U F-TEID value. Otherwise, the SGW shall 
return the currently allocated GTP-U F-TEID value. See 
NOTE 1 


F-TEID 





S12SGW F-TEID 


C 


This IE shall be included on the S4 interface if the S12 
interface is being used. If the 'Change F-TEID support 
Indication' flag was set to 1 in the Modify Bearer Request 
and the SGW needs to change the F-TEID, the SGW shall 
include the new GTP-U F-TEID value. Otherwise, the SGW 
shall return the currently allocated GTP-U F-TEID value. 

OW IMW 1 m 1 


F-TEID 


1 


S4-U SGW F-TEID 


C 


This IE shall be present if used on the S4 interface if the 
S4-U interface is being used. If the 'Change F-TEID 
support Indication' flag was set to 1 in the Modify Bearer 
Request and the SGW needs to change the F-TEID, the 
SGW shall include the new GTP-U F-TEID value. 
Othenwise, the SGW shall return the currently allocated 
GTP-U F-TEID value. See NOTE 1 


F-TEID 


2 




C 


This IE shall be present on the S5/S8 interface if this 
message is triggered due to one of the following 
procedures: 

- TAU/RAU/HO with SGW relocation 






Charging ID 




- TAU/RAU/HO from Gn/Gp SGSN to MME/S4- 
SGSN 


Charging ID 








If S5/S8 interface is GTP, this IE may be sent on the S4 
interface, in order to support CAMEL charging at the 
SGSN, for the following procedures: 

inter-SGSN RAU/Handover/SRNS Relocation 

without SGW change. 

inter-SGSN Handover/SRNS Relocation with SGW 

change. 




Bearer Flags 


CO 


Applicable flags are: 

PPC (Prohibit Payload Compression): This flag 
shall be sent on the S5/S8 and the S4 interfaces at 
S4-SGSN relocation. 


Bearer Flags 





NOTE 1 : The SGW shall not change its F-TEID for a given interface during the Handover, Service Request, E- 
UTRAN Initial Attach, UE Requested PDN connectivity and PDP Context Activation procedures. The 
SGW F-TEID shall be same for S1-U, S4-U and S12. 

During Handover and Service Request the target eNodeB/RNC/SGSN may use a different IP type 
than the one used by the source eNodeB/RNC/SGSN. In order to support such a scenario, the SGW 
F-TEID should contain both an IPv4 address and an IPv6 address (see also subclause 8.22 "F- 
TEID"). 
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Table 7.2.8-3: Bearer Context marked for removal within lUlodify Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


= n 


:06tet4 _ , , 


■l^^^^^^^^pare Instanc^^^^^^^^^^^^^^^^^^H 


Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 






7.2.9 Delete Session Request and Delete Bearer Request 
7.2.9.1 Delete Session Request 

The direction of this message shaU be from MME/S4-SGSN to SGW, from SGW to PGW and from TWAN/ePDG to 
PGW (see Table 6.1-1). 

A Delete Session Request message shall be sent on the SI 1 interface by the MME to the SGW and on the S5/S8 
interface by the SGW to the PGW as part of the procedures: 

- EUTRAN Initial Attach 

- UE, HSS or MME Initiated Detach 

- UE or MME Requested PDN Discormection 

It shall also be sent on the S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the SGW to the PGW 
as part of 

- MS, HLR or SGSN initiated detach procedure 

- Combined GPRS/IMSI Attach 

- MS and SGSN Initiated PDN connection Deactivation Procedure using S4 
On the S 11 interface by the MME to the SGW as part of the procedures: 

Tracking Area Update with SGW Change 

- S 1 Based Handover with SGW Change 

- X2 Based Handover with SGW Relocation 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 

- Inter RAT handover cancel with SGW change 

- MME to 3G Gn/Gp SGSN combined hard handover and SRNS relocation procedure 

- MME to SGSN Routing Area Update 

- E-UTRAN to Gn/Gp SGSN Inter RAT handover 

- SI Based handover cancel with SGW change 

- Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access 
And on the S4 interface by the SGSN to the SGW as part of 

- Enhanced Serving RNS Relocation with SGW relocation using S4 

- Routing Area Update with SGW change 
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- SGSN to MME Tracking Area Update with SGW change 

- SRNS Relocation Cancel Procedure Using S4 

- Inter RAT with SGW change handover cancel 

- Serving RNS relocation with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

- S4 SGSN to Gn/Gp SGSN Routeing Area Update 

- S4 SGSN to Gn/Gp SGSN Serving RNS Relocation Procedures 

- S4 SGSN to Gn/Gp SGSN PS handover Procedures 

The message shall also be sent on the S2b interface by the ePDG to the PGW as part of procedures: 

- UE/ePDG Initiated Detach with GTP on S2b 

- UE Requested PDN Disconnection with GTP on S2b 

- HSS/AAA Initiated Detach with GTP on S2b 

The message shall also be sent on the S2a interface by the TWAN to the PGW as part of procedures: 

- UE/TWAN Initiated Detach and UE/TWAN Requested PDN Disconnection in WLAN on GTP S2a 

- HSS/AAA Initiated Detach in WLAN on GTP S2a 

This message may also be sent on S5/S8 interface by the SGW to the PGW: 

- If Downlink Data Notification Acknowledge message with Context not foimd cause value is received. 

During the detach procedure, if ISR is active and SGW receives a Delete Session Request, the SGW shall deactivate the 
ISR. 

NOTE: The SGW can determine if it is a detach procedure based on e.g. it receives a Delete Session Request 
message for the last PDN Connection. 

When ISR is active, during the Detach procedure the SGW shall forward the Delete Session Request message to the 
PGW on the S5/S8 interface after receiving both of the messages sent from the MME and the SGSN for the same PDN 
Connection. 

If there are any procedure collisions, the Delete Session Request shall have precedence over any other Turmel 
Management message. 

During the handover procedure the Delete Session Request message shall not release the indirect data forwarding 
tunnels. 

Possible Cause values are: 

- "ISR deactivation ". 

- "Network Failure". 

"QoS parameter mismatch". 
Table 7.2.9.1-1 specifies the presence of the lEs in the message. 
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Table 7.2.9.1-1: Information Elements in a Delete Session Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


C 


If ISR is being de-activated, tlie Cause IE stiall be included 
on tlie S4/S1 1 interface with the value "ISR deactivation", 
which indicates that the SGW shall delete the bearer 
resources by sending Delete Bearer Request to the 
IVIME/SGSN on which ISR was activated with the same 
Cause value "ISR deactivation". See NOTE 3 


Cause 





CO 


The MME/SGSN should include this IE if the message is 
sent due to a network failure as specified in subclause 15.7 
of 3GPP TS 23.060 [35] and subclause 5.18 of 3GPP TS 
23.401 [3]. It indicates to the PGW the reason of the 
failure. 

The SGW shall include this IE on S5/S8 if it receives the 
Cause from the MME/SGSN. 




Linked EPS Bearer ID 
(LBI) 


c 


This IE shall be included on the S4/S1 1 , S5/S8 and 
S2a/S2b interfaces to indicate the default bearer 
associated with the PDN being disconnected unless in the 
handover/TAU/RAU with SGW relocation procedures. 


EBI 





User Location 
Information (ULI) 


c 


The MME/SGSN shall include this IE on the S4/S1 1 
interface for the Detach procedure. The MME shall include 
ECGI, SGSN shall include CGI/SAI. The SGW shall 
include this IE on S5/S8 if it receives the ULI from 
MME/SGSN. 


ULI 





CO 


The MME/SGSN shall include this IE on the S4/S1 1 
interface for the UE or MME Requested PDN 
Disconnection procedure/MS and SGSN Initiated PDN 
connection Deactivation Procedure using S4. 
The MME shall include ECGI, SGSN shall include 
CGI/SAI. 

The SGW shall include this IE on S5/S8 if it receives the 
ULI from the MME/SGSN. 


Indication Flags 


c 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Operation Indication: This flag shall be set over 
S4/S1 1 interface if the SGW needs to forward the 
Delete Session Request message to the PGW. 
This flag shall not be set if the ISR associated GTP 
entity sends this message to the SGW in the 
Detach procedure. This flag shall also not be set to 
1 in the SRNS Relocation Cancel Using S4 
(6.9.2.2.4a in 3GPP TS 23.060 [4]), Inter RAT 
handover Cancel procedure with SGW change 
TAU with Serving GW change, Gn/Gb based RAU 
(see 5.5.2.5, 5.3.3.1 , D.3.5 in 3GPP TS 23.401 [3], 
respectively), SI Based handover Cancel 
procedure with SGW change. 

This flag shall also not be set for, e.g., X2 based 
handover procedure with SGW change(see 
subclause 5.5.1 .1 .3 in 3GPP TS 23.401 [3]), or SI 
based handover procedure with SGW change (see 
subclause 5.5.1 .2.2 in 3GPP TS 23.401 [3]). 

Scope Indication: if request corresponds to 
TAU/RAU/Handover with SGW change/SRNS 
Relocation Cancel Using S4 with SGW change. 
Inter RAT handover Cancel procedure with SGW 
change, SI Based handover Cancel procedure 
with SGW change, then this bit shall be set on the 
S4/S11 interface. 

See NOTE 1 . 


Indication 
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Protocol 

Configuration Options 
(PCO) 


C 


If the UE includes the PCO IE, then the MME/SGSN shall 
copy the content of this IE transparently from the PCO IE 
included by the UE. 

If SGW receives the PCO IE, SGW shall forward it to 
PGW. 


PCO 





Originating Node 


C 


This IE shall be included on the S4/S1 1 Interface if the ISR 
is active in MME/SGSN to denote the type of the node 
originating the message. 

The SGW shall release the corresponding Originating 
Node related EPS Bearer contexts information in the PDN 
Connection identified by the LBI. 


Node Type 









Sender F-TEID for 
Control Plane 





This IE may be included on the S4/S1 1 interfaces. 
If the Sender F-TEID for Control Plane is received by the 
SGW, the SGW shall only accept the Delete Session 
Request message when the Sender F-TEID for Control 
Plane in this message is the same as the Sender F-TEID 
for Control Plane that was last received in either the Create 
Session Request message or the Modify Bearer Request 
message on the given interface. 

If the ISR is activated, two F-TEIDs exist: one for the MME 
and the other for the SGSN. See NOTE 2. 


F-TEID 





UE Time Zone 


CO 


This IE shall be included by the MME on the S1 1 interface 
or by the SGSN on the S4 interface, for Detach and PDN 
Disconnection procedures, if the UE Time Zone has 
changed. 


UE Time Zone 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN, and if the Operation Indication bit received 
from the MME/SGSN is set to 1 . 


Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


VS 


NOTE 1 : For the Indication Flags, the combination (Operation Indication, Scope Indication) = 1 ,1 shall be 

considered an error if received. 
NOTE 2: Following an inter RAT TAU/RAU failure, the target MME/SGSN may mistakenly initiate the implicit 

detach procedure while the UE is managed by the other MME/SGSN. In this case, the SGW will 

reject the Delete Session Request message with the cause "Invalid peer". 
NOTE 3: If the UE has multiple PDN connections and only one of these is being deactivated, the MME/S4- 

SGSN shall not send the Cause IE with the value "ISR deactivation". 



7.2.9.2 Delete Bearer Request 

The direction of this message shaU be from PGW to SGW, from SGW to MME/S4-SGSN and from PGW to 
TWAN/ePDG (see Table 6.1-1). 

A Delete Bearer Request message shall be sent on the S5/S8 and S4/S1 1 interfaces as part of the following procedures: 

- PGW or MME initiated bearer deactivation procedures, 

- UE requested Bearer Resource Modification, 

MS and SGSN Initiated Bearer Deactivation procedure using S4 or 

PGW initiated bearer deactivation procedure using S4. 

In the above cases, this Request is sent by the PGW to the SGW and shall be forwarded to the MME or S4-SGSN. 

The message shall also be sent on the S4/S1 1 interface by the SGW to the SGSN/MME to delete the bearer resources on 
the other ISR associated CN node if the ISRAl flag is not set in the Modify Bearer Request/Modify Access Bearers 
Request message. 

The message shall also be sent on the S4/S11 interface by the SGW to the SGSN/MME to delete the bearer resources on 
the other ISR associated CN node in the TAU/RAU/Handover procedures if the ISR related Cause IE is included in the 
Delete Session Request message. 
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The message shall also be sent on the S2b interface by the PGW to the ePDG as part of PGW Initiated Bearer Resource 

Allocation Deactivation procedure with OTP on S2b. 

The message shall also be sent on the S2a interface by the PGW to the TWAN as part of the PGW Initiated Bearer 
Resource Allocation Deactivation in WLAN on GTP on S2a procedure. 

The message may also be sent on the S11/S4 interface by the SGW to the MME/S4 SGSN when the SGW receives the 
Error Indication from PGW for the default bearer as specified in 3GPP TS 23.007 [17]. 

Possible Cause values are: 

- "RAT changed from 3GPP to Non-3GPP", 

- "ISR deactivation", 

- "Access changed from Non-3GPP to 3GPP", 
"Reactivation requested", 

- "PDN reconnection to this APN disallowed", 
"PDN connection inactivity timer expires". 

Table 7.2.9.2-1 specifies the presence of lEs in this message. 
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Table 7.2.9.2-1 : Information Elements in a Delete Bearer Request 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










Linked EPS Bearer ID 
(LBI) 


C 


If tlie request corresponds to the bearer deactivation 
procedure in case all bearers belonging to a PDN 
connection shall be released, then this IE shall be included 

on the 85/88, 84/81 1 and 82a/82b interfaces to indicate 
the default bearer associated with the PDN being 
disconnected. 

This IE shall be included only when the EPS Bearer ID is 
not present in the message. 


EBI 







GO 


During a TAU/RAU/HO if the Cause value is set to "I8R 
deactivation" in the Delete Session Request message, or 
when this message is used to delete the bearer resources 
on the other I8R associated CN node if the I8RAI flag is 
not set in the IVIodify Bearer Request/IVIodify Access 
Bearers Request message, an SGW shall send all LBIs for 
a given UE with the message on S4/S1 1 interface. All LBI 
lEs shall have the same type and instance value to 
represent a list of lEs (see NOTE 1 and NOTE 2). 






EPS Bearer IDs 


C 


This IE shall be used on 85/88, 84/81 1 and 82a/82b 
interfaces for bearers different from the default one, i.e., for 
dedicated bearers. In this case at least one dedicated 
bearer shall be included. 

Several lEs with this type and instance values shall be 

included as necessary to represent a list of Bearers. 


EBI 


1 


Failed Bearer 





This IE may be included on the 85/88 and 81 1 interfaces if 


Bearer Context 





Contexts 




the request corresponds to IVIIVIE initiated bearer 
deactivation procedure. This IE shall contain the list of 
failed bearers if partial Bearer Contexts included in the 
Delete Bearer Command message could not be deleted. 






Procedure 
Transaction Id (PTI) 


C 


If the request corresponds to UE requested bearer 
resource modification procedure for an E-UTRAN, this IE 
shall be included on the 85/88 and 81 1 interfaces. 


PTI 





Protocol 

Configuration Options 
(PCO) 


C 


PGW shall include Protocol Configuration Options (PCO) 

1 l~~ X 1 ^ //^ rt"x_£ 'ill — 

IE on the S5/S8 interface, if available. 

If SGW receives this IE, SGW shall fonward it to 

8G8N/MME on the 84/81 1 interface. 


PCO 





PGW-FQ-CSID 





This IE shall be included by the PGW on the 85/88 and 
82a/82b interfaces, and when received from 85/88 be 
forwarded by the SGW on the 81 1 interface according to 
the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by the SGW on the S1 1 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Cause 





This IE shall be sent on 85/88 and 81 1/84 interfaces if the 
message is caused by a handover with or without 
optimization from 3GPP to non-3GPP (see subclause 9.3.2 
in 3GPP TS 23.402 [45] and subclause 5.4.4.1 in 3GPP TS 
23.401 [3], respectively). In this case the Cause value shall 
be set to "RAT changed from 3GPP to Non-3GPP". 
This IE shall also be sent on 81 1/84 interfaces when the 
SGW requests to delete all bearer contexts for the given 
UE in an IVIME or 84-8G8N due to I8R deactivation, and 
the Cause value shall be set to "ISR deactivation". 
This IE shall be sent on the S2a/S2b interface if the 
message is caused by handover from non-3GPP to 3GPP. 
In this case the Cause value shall be set to "Access 
changed from Non-3GPP to 3GPP . 


Cause 







u 


1 his It may be sent by a PGW on 00/08 during PGW 
initiated PDN connection deactivation procedures with 
values of "Reactivation requested" or " PDN reconnection 
to this APN disallowed " (see section 8.4 for details). 











This IE may be sent by a PGW on 85 during PGW initiated 

PDN connection deactivation procedures with values of 
"PDN connection inactivity timer expires" (see section 8.4 
for details). 








CO 


The IE shall be relayed by the SGW to the MME/S4-SGSN 
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if received from tlie PGW. 



Private Extension 



O 



Tliis IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 



Private Extension 



VS 



NOTE 1 : If the SGW has sent multiple LBIs to IVIME/SGSN, but have received only one LBI within the Delete 
Bearer Response message, this indicates that the IVIME/SGSN is pre Rel-10. In such case, the SGW 
shall send separate individual Delete Bearer Request message(s) for each of remaining LBIs. 

NOTE 2: If the SGW has received Delete Session Request with Cause value set to "ISR deactivation" and has 
subsequently sent a Delete Bearer Request to the MME/SGSN with Cause value set to "ISR 
deactivation", then the MME/SGSN shall delete all PDN connections correspondinq to all of the LBIs 
received in the Delete Bearer Request messaqe for this UE. The IVIME/SGSN shall ignore any LBIs 

for which there are no matchinq PDN connections correspondinq to these LBIs. 



NOTE: In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure 
for an E-UTRAN as specified by 3GPP TS 24.301 [23], then there will be only one instance of the EPS 
Bearer IDs IE in the Delete Bearer Request. 

Table 7.2.9.2-2: Bearer Context within Delete Bearer Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate the reason of the unsuccessful 
handling of the bearer. 


Cause 






7.2.10 Delete Session Response and Delete Bearer Response 
7.2.10.1 Delete Session Response 

A Delete Session Response message shall be sent on the Sll interface by the SGW to the MME and on the S5/S8 
interface by the PGW to the SGW as part of the following procedures: 

- EUTRAN Initial Attach 

- UE, HSS or MME Initiated Detach 

- UE or MME Requested PDN Disconnection 

It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interface by the PGW to the SGW as 
part of the procedures: 

- MS, HLR or SGSN initiated detach procedure 

- Combined GPRS/IMSI Attach 

MS and SGSN Initiated Default Bearer Deactivation Procedure using S4 
On the Sll interface by the SGW to the MME as part of the procedures: 
Tracking Area Update with SGW Change 

- S 1 Based Handover with SGW Change 
X2 Based Handover with SGW Relocation 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode hiter RAT handover with SGW change 
Inter RAT handover cancel with SGW change 

- MME to 3G Gn/Gp SGSN combined hard handover and SRNS relocation procedure 
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- MME to SGSN Routing Area Update 

- E-UTRAN to Gn/Gp SGSN Inter RAT handover 

- SI Based handover cancel with SGW change 

- Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access 
And on the S4 interface by the SGW to the SGSN as part of the procedures: 

Enhanced Serving RNS Relocation with SGW relocation using S4 

- Routing Area Update with SGW change 

- SGSN to MME Tracking Area Update with SGW change 

- Serving RNS relocation with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

- S4 SGSN to Gn/Gp SGSN Routeing Area Update 

- S4 SGSN to Gn/Gp SGSN Serving RNS Relocation Procedures 

- S4 SGSN to Gn/Gp SGSN PS handover Procedures 

The message shall also be sent on the S2b interface by the PGW to the ePDG as part of procedures: 

- UE/ePDG Initiated Detach with GTP on S2b 

- UE Requested PDN Disconnection with GTP on S2b 

- HSS/AAA Initiated Detach with GTP on S2b 

The message shall also be sent on the S2a interface by the PGW to the TWAN as part of procedures: 

- UE/TWAN Initiated Detach and UE/TWAN Requested PDN Disconnection in WLAN on GTP S2a 

- HSS/AAA Initiated Detach in WLAN on GTP S2a 

This message may also be sent on S5/S8 interface by the PGW to the SGW: 

- If Downlink Data Notification Acknowledge message with Context not foimd cause value is received. 

The sending entity shall include Cause IE in the Delete Session Response message. The IE indicates if the peer has 
deleted the bearer, or not. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 
"Context not found". 
"Invalid peer". 

Table 7.2.10.1-1 specifies the presence of the lEs in the message. 



ETSI 



3GPP TS 29.274 version 1 1 .5.0 Release 1 1 75 ETSI TS 1 29 274 V1 1 .5.0 (201 3-01 ) 



Table 7.2.10.1-1: Information Elements in a Delete Session Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 


(J 


Recovery 


c 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces if contacting the peer for the first time 


Recovery 





Protocol 

Configuration Options 
(PCO) 


c 


PGW shall include Protocol Configuration Options (PCO) 
IE on the S5/S8 interface, if available. 
If SGW receives this IE, SGW shall forward it to 
SGSN/MME on the S4/S1 1 interface. 


PCO 





Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


vs 



7.2.10.2 Delete Bearer Response 

The Delete Bearer Response shall be sent as a response of Delete Bearer Request. 
Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially" . 

"Context not found". 
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Table 7.2.10.2-1: Information Elements in Delete Bearer Response 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










Cause 


IVI 




Cause 





Linked EPS Bearer ID 
(LBI) 


c 


If the response corresponds to the bearer deactivation 
procedure in case all the bearers associated with the 

default bearer of a PDN connection shall be released, this 
IE shall be included on the S4/S1 1 , S5/S8 and S2a/S2b 
interfaces to indicate the default bearer associated with the 
PDN being disconnected. 


EBI 







CO 


During a TAU/RAU/HO, if an MME/SGSN has received a 
Delete Bearer Request message with Cause value "ISR 
deactivation" and multiple LBIs, the MME/SGSN shall 

include all these LBIs in the response message on S4/S1 1 
interface. All LBI lEs shall have the same type and 
instance value to represent a list of IBs. 






Bearer Contexts 


c 


It shall be used on the S4/S1 1 , S5/S8 and S2a/S2b 
interfaces for bearers different from default one. In this 

case at least one bearer shall be included. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 
Used for dedicated bearers. When used, at least one 
dedicated bearer shall be present. 


Bearer Context 





Recovery 


c 


This IE shall be included on the S4/S1 1 , S5/S8 and 
S2a/S2b interfaces if contacting the peer for the first time 


Recovery 





MME-FQ-CSID 


c 


This IE shall be included by MME the on S1 1 interface and 
shall be forwarded by the SGW on S5/S8 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


c 


II — _i II 1 : 1 . . _i 1 1 . i.1 — J.I O ^ /O 

This IE shall be included by the SGW on the S5/S8 
interface according to the requirements in 3GPP TS 

23.007 [17]. 


FQ-CSID 


1 


ePDG-FQ-CSID 


c 


^ni 1 l~~ 1 III 1 1 11 xl i~* xl ^ rw ■ X J 

This IE shall be included by the ePDG on the S2b interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


2 


TWAN-FQ-CSID 


c 


^ni 1 1~~ 1 III 1 1 11 xl 1 1 A f A K 1 xl 

This IE shall be included by the TWAN on the S2a 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 


3 


Protocol 


CO 


An MME/SGSN shall include the PCO IE if such 


PCO 





Configuration Options 
(PCO) 




information was received from the UE. 

\Z. X 1 A / xl ■ 1 l~~ xl A f 1 \\ L. 1 ' X X 

If the SGW receives this IE, the SGW shall forward it to 
PGW on the S5/S8 interface. 











^Fl 1 l~~ X" II r 1 II xP KARA |~~ 1 1 J J 

This IE IS optionally included by the MME on the 81 1 
interface or by the SGSN on the 84 interface. 






UE Time Zone 


CO 


^ni /^\ A / 1 1 1 r 1 X 1 ■ 1 1~~ X 1 j— r\ ' l i. xi 

The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
IVIIVIt/oooN. 


UE Time Zone 







CO 


This IE shall be included by the MME on the S1 1 interface 
or by the SGSN on the S4 interface. The CGI/SAI shall be 






User Location 




included by SGSN and the ECGI shall be included by 


ULI 




Information (ULI) 




MME. 







CO 


The SGW shall forward this IE on the S5/S8 interface if it 
receives it from the MME/SGSN. 






Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


VS 
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Table 7.2.10.2-2: Bearer Context within Delete Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 




Q&MA. 


^^^^^^^I^pare and.lnstanc^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 





Protocol 

Configuration Options 
(PCO) 


CO 


An MME/SGSN shall include the PCO IE if such 

information was received from the UE. 

If the SGW receives this IE, the SGW shall forward it to 

PGW on the S5/S8 interface. 

This bearer level IE takes precedence over the PCO IE in 
the message body if they both exist. 


PCO 






7.2.1 1 Downlink Data Notification messages 
7.2.1 1 .1 Downlink Data Notification 

A Downlink Data Notification message shall be sent: 

- on the SI 1 interface by the SGW to the MME as a part of the network triggered service request procedure; 

- on the S4 interface by the SGW to the S4-SGSN as part of Paging with no estabhshed user plane on S4, SGW 
triggered paging with S4; 

on the S4 interface by the SGW to the S4-SGSN to re-establish all the previous released bearer(s) for a UE, upon 
receipt of downlink data for a UE in connected mode but without corresponding downlink bearer available; 

NOTE: This may occur e.g. if the S4-SGSN releases some but not all the bearers of the UE as specified in 
subclause 12.7.2.2 of 3GPP TS 23.060 [35]. 

- on SI 1/S4 interface by SGW to MME/S4-SGSN if the SGW has received an Error Indication (see 3GPP TS 
29.281 [13]) from eNodeB/RNC across S1-U/S12 interface. Respective SGW and MME/S4-SGSN functionaUty 

is specified in 3GPP TS 23.007 [17]. 

- on the SI 1/S4 interface by SGW to the MME/S4-SGSN as part of the network triggered service restoration 
procedure if both the SGW and the MME/S4-SGSN support this optional feature (see 3GPP TS 23.007 [17]). 

A Downlink Data Notification message may be sent: 

- on the S4 by the SGW to the S4-SGSN if the SGW has received an Error Indication from S4-SGSN across S4-U 
interface. 

Table 7.2.1 1.1-1 specifies the presence of the lEs in the message. 
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Table 7.2.11.1-1: Information Elements in a Downlink Data Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


CO 


If SGW receives an Error Indication from eNodeB/RNC/S4- 
SGSN, the SGW shall send the Cause IE with value "Error 
Indication received from RNC/eNodeB/S4-SGSN" to 
IVIIVIE/S4-SGSN as specified in 3GPP TS 23.007 [17]. 


Cause 





EPS Bearer ID 


CO 


This IE shall be included on the S1 1 and S4 interfaces and 

shall be set as follows: 

If the Downlink Data Notification is triggered by 
the arrival of downlink data packets at the SGW, 
the SGW shall include the EPS Bearer ID stored 
in the EPS bearer context of the bearer on which 
the downlink data packet was received; 
If the Downlink Data Notification is triggered by 
the receipt of an Error Indication from the eNodeB 
or RNC, the SGW shall include the EPS Bearer 
ID stored in the EPS bearer context of the bearer 
for which the Error Indication was received; 
If the ISR is active and the Downlink Data 
Notification is triggered by the arrival of control 
plane signalling, the SGW shall include the EPS 
Bearer ID present in the control plane signalling. 
If both the SGW and the l\/IME/S4-SGSN support 
the network triggered service restoration 
procedure (see 3GPP TS 23.007 [17]), and if the 
Downlink Data Notification is triggered by the 
arrival of control plane signalling, the SGW shall 
include the EPS Bearer ID present in the control 
plane signalling. 

(See 3GPP TS 23.401 [3], section 5.3.4.3). 

More than one IE with this type and instance values may 
be included to represent multiple bearers having received 
downlink data packets or being signalled in the received 
control plane message. 
See NOTE 1 . 


EBI 





Allocation/Retention 
Priority 


CO 


This IE shall be included on the S1 1 and S4 interfaces and 

shall be set as follows: 

If the Downlink Data Notification is triggered by 
the arrival of downlink data packets at the SGW, 
the SGW shall include the ARP stored in the EPS 
bearer context of the bearer on which the 
downlink data packet was received; 
If the Downlink Data Notification is triggered by 
the receipt of an Error Indication from the eNodeB 
or RNC, the SGW shall include the ARP stored in 
the EPS bearer context of the bearer for which 
the Error Indication was received. 
If the ISR is active and the Downlink Data 
Notification is triggered by the arrival of control 
plane signalling, the SGW shall include the ARP if 
present in the control plane signalling. If the ARP 
is not present in the control plane signalling, the 
SGW shall include the ARP in the stored EPS 
bearer context. 

If both the SGW and the MME/S4-SGSN support 
the network triggered service restoration 
procedure (see 3GPP TS 23.007 [17]), and if the 
Downlink Data Notification is triggered by the 
arrival of control plane signalling, the SGW shall 
include the ARP if present in the control plane 
signalling. If the ARP is not present in the control 
plane signalling, the SGW shall include the ARP 
from the stored EPS bearer context. 

(See 3GPP TS 23.401 [3], section 5.3.4.3). 

If multiple EPS Bearers IDs are reported in the message, 


ARP 
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the SGW shall include the ARP associated with the bearer 
with the highest priority (i.e. the lowest ARP value). 
See NOTE 1 . 






IMSI 


CO 


This IE shall be included on the S1 1/S4 interface as part of 
the network triggered service restoration procedure if both 
the SGW and the MME/S4-SGSN support this optional 
feature (see 3GPP TS 23.007 [1 7]). 


IMSI 





Sender F-TEID for 
Control Plane 





This IE may be included on the S1 1/S4 interface towards 
the restarted CN node or an alternative CN node (same 
type of mobility node as the failed one) as part of the 
network triggered service restoration procedure with or 
without ISR if both the SGW and the MI\/IE/S4-SGSN 
support this optional feature (see 3GPP TS 23.007 [17]). 
This IE shall not be included otherwise. 
(NOTE 2) 


F-TEID 





Private Extension 







Private Extension 


VS 


NOTE 1 : The usage of this parameter at the S4-SGSN is not specified in this release. 

NOTE 2: In this version of the specification, the MME/S4-SGSN shall set the header TEID value in subsequent 
Downlink Data Notification Acknowledge or/and Downlink Data Notification Failure Indication to that 
of the SGW's Control Plane TEID if the Sender F-TEID for Control Plane IE is present in the 
Downlink Data Notification message. However the SGW shall be prepared to receive messages in 
which the header TEID value is set to zero from implementation conforming to earlier versions of this 
specification. When that is the case, the receiver identifies the subscriber context based on the 
included IMSI IE. 



7.2.1 1 .2 Downlink Data Notification Aoknowiedge 

A Downlink Data Notification Acknowledge shall be sent from a MME/SGSN to a SGW in response to Downlink Data 
Notification with an indication of success, or failure when MME/SGSN has reachability or abnormal conditions. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

- "Unable to page UE". 

"Context not found". 

"Unable to page UE due to Suspension". 

"UE already re-attached" . 
Table 7.2.11.2-1 specifies the presence of the lEs in the message. 
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Table 7.2.11.2-1: Information Elements in a Downlink Data Notification Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Data Notification 
Delay 


C 


The MME/SGSN shall include an adaptive delay indication 
to the SGW to delay the number of Data Notification 

indications, if the rate of Downlink Data Notification event 
occurrence in the MME/SGSN becomes significant (as 
configured by the operator) and the MME/SGSN's load 
exceeds an operator configured value. 


Delay Value 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





DL low priority traffic 
Throttling 





The MME/SGSN may send this IE to the SGW to request 
the SGW to reduce the number of Downlink Data 
Notification requests it sends for downlink low priority traffic 
received for UEs in idle mode served by that MME/SGSN 
in proportion to the Throttling Factor and during the 
Throttling Delay. 

See NOTE 1 , NOTE 2, NOTE 3. 


Throttling 





IMSI 


CO 


3GPP TS 23.007 [17] specifies conditions for sending this 
IE on the SI 1/S4 interface as part of the network triggered 
service restoration procedure, if both the SGW and the 
MME/S4-SGSN support this optional feature. 


IMSI 





Private Extension 







Private Extension 


vs 


NOTE 1 : The last received value of the Throttling Factor and Throttling Delay shall supersede any previous 
values received from that l\/ll\/IE/SGSN. The reception of a Throttling Delay shall restart the SGW 
timer associated with that MME/SGSN. The SGW shall determine whether a bearer is for low priority 
traffic or not on the basis of the bearer's ARP priority level and operator policy (i.e. operator's 
configuration in the SGW of the ARP priority levels to be considered as prioritary or non-prioritary 
traffic). 

NOTE 2: For instance, if the DL low priority traffic Throttling IE indicates a Throttling Factor of 40% and a 

Throttling Delay of 180 seconds, the SGW drops by 40% the number of Downlink Data Notification 
requests it sends for downlink low priority traffic received for UEs in idle mode served by that 
MME/SGSN, during a period of 180 seconds. 

NOTE 3: The DL low priority traffic Throttling IE may be present whatever the value of the Cause IE. 



7.2.1 1 .3 Downlink Data Notification Failure Indication 

A Downlink Data Notification Failure indication shall be sent from an MME/SGSN to a SGW indicating that the UE 
did not respond to paging. It shall also be sent in the case that the UE responded to the page with a Service Request but 
that the MME has rejected the request by sending a Service Reject to the UE. It may happen, for example, because the 
requested service is not supported or there is a bearer context mismatch. 

This message should not be used after an MME/SGSN successfully receives the Service Request message from the UE 
in the Network Triggered Service Request procedure as defined in the 3GPP TS 23.401 [3]. 

NOTE: Either the Modify Bearer Request message or the Delete Bearer Command message is used by the 

MME/SGSN to indicate a possible failure case after an MME/SGSN successfully receives the Service 
Request message from the UE. 

Possible Cause values are: 

"UE not responding". 

"Service denied". 

"UE already re-attached" . 
Table 7.2.11.3-1 specifies the presence of the lEs in the message. 
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Table 7.2.11.3-1: Information Elements in a Downlink Data Notification Failure Indication 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










Cause 


M 




Cause 





Originating Node 


CO 


This IE shall be included on the S4/S1 1 interface if the ISR 
associated QTP entities i.e. MME, S4-SGSN, send this 
message to the SGW during the Network Triggered 
Service Request procedure to denote the type of the node 
originating the message. 


Node Type 





IIVISI 


CO 


3GPP TS 23.007 [1 7] specifies conditions for sending this 
IE on the S1 1/S4 interface as part of the network triggered 
service restoration procedure, if both the SGW and the 
l\/IME/S4-SGSN support this optional feature. 


IMSI 





Private Extension 







Private Extension 


vs 



7.2.12 Delete Indirect Data Forwarding Tunnel Request 

The Delete Indirect Data Forwarding Tunnel Request message is sent on the S4/S1 1 interface by the SGSN/MME to the 
SGW to delete the Indirect Forwarding Tunnels in the Source SGW/Target SGW as part of the following procedures: 

- SI -based handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- MME to 3G SGSN combined hard handover and SRNS relocation procedure 

- 3G SGSN to MME combined hard handover and SRNS relocation procedure 

- Inter RAT handover Cancel 

- S 1 -based handover Cancel 

- Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access 



Table 7.2.12-1: Information Element in Delete Indirect Data Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 





Vendor or operator specific information 


Private Extension 


VS 



7.2.13 Delete Indirect Data Forwarding Tunnel Response 

The Delete Indirect Data Forwarding Tunnel Response message is sent on the S4/S 1 1 interface by the SGW to the 
SGSN/MME as part of the following procedures: 

SI -based handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- MME to 3G SGSN combined hard handover and SRNS relocation procedure 
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- 3G SGSN to MME combined hard handover and SRNS relocation procedure 

- Inter RAT handover Cancel 

- S 1 -based handover Cancel 

- Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access 
Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 
"Request accepted partially" 

- "Context not found". 



Table 7.2.13-1: Information Element in Delete Indirect Data Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 


This IE shall indicate if the deletion of indirect tunnel is 
successful, and if not, gives information on the reason. 


Cause 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 



7.2.14 Modify Bearer Command and Failure Indication 
7.2.14.1 Modify Bearer Command 

The Modify Bearer Command shall be sent on the Sll interface by the MME to the SGW and on the S5/S8 interface by 
the SGW to the PGW as part of the HSS Initiated Subscribed QoS Modification procedure or SQCI flag is set to 1 in the 
Context Response message. 

It shall also be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interface by the SGW to the PGW as 
part of the HSS Initiated subscribed QoS modification procedure or SQCI flag is set to 1 in the Context Response 
message. 

It shall also be sent on the S2a/S2b interface by the TWAN/ePDG to the PGW as part of the HSS Initiated Subscribed 
QoS Modification procedure. 



Table 7.2.14.1-1: Information Elements in a Modify Bearer Command 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


APN-Aggregate 
IVlaximum Bit Rate 
(APN-AIVIBR) 


M 


This IE shall contain the APN-AIVIBR value received by the 
MME/SGSN/ TWAN/ePDG from the HSS. 


AMBR 





Bearer Context 


M 


Only one IE with this type and Instance value shall be 
included and this shall represent the Default Bearer. 


Bearer Context 





Private Extension 





This IE may be sent on the 85/88, 84/81 1 and 82a/82b 
interfaces. 


Private Extension 


V8 
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Table 7.2.14.1-2: Bearer Context within lUlodify Bearer Command 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


^^^^^^^^^^ = n 


UsmlA 


■l^^^^^^^^pare instano^^^^^^^^^^^^^^^^^^ft 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 


This IE shall contain the default bearer ID. 


EBI 





Bearer Level QoS 


C 


IVIandatory if other parameters than the APN-AIVIBR have 
been changed 


Bearer QoS 





CO 


This IE shall also be included when QCI and ARP have not 
been changed and if the SQCI flag is set to 1 in the 
Context Response message. 



7.2.14.2 Modify Bearer Failure Indication 

The Modify Bearer Failure Indication shall be sent on the S5/S8 interface by the PGW to the SGW and on the SIX 
interface by the SGW to the MME as part of failure of HSS Initiated Subscribed QoS Modification procedure or SQCI 
flag is set to 1 in the Context Response message. 

It shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to the SGSN as 
part of failure of HSS Initiated subscribed QoS modification or SQCI flag is set to 1 in the Context Response message. 

It shall also be sent on the S2a/S2b interface by the PGW to the TWAN/ePDG as part of failure of HSS Initiated 
Subscribed QoS Modification procedure. 

Cause IE indicates that an EPS bearer has not been updated in the PGW. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Context not found" 

"Service denied". 



Table 7.2.14.2-1: Information Elements in a Modify Bearer Failure Indication 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










Cause 


M 




Cause 





Recovery 


C 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces if contacting the peer for the first time 


Recovery 





Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


VS 



7.2.15 Update Bearer Request 

The direction of this message shall be from PGW to SGW and/or from SGW to MME/S4-SGSN, and/or from PGW to 
TWAN/ePDG (see Table 6.1-1). 

For GTP based S5/S8, the Update Bearer Request shall be sent by the PGW to the SGW and forwarded to the MME as 
part of the following procedures: 

- PGW Initiated Bearer Modification with Bearer QoS Update 

- HSS Initiated Subscribed QoS Modification 

- PGW Initiated Bearer Modification without Bearer QoS Update 

- UE Request Bearer Resource Modification procedure (see 3GPP TS 24.301 [23]) 

- UE requested bearer resource allocation procedure (see 3GPP TS 24.301 [23]) 
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The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
the SGSN as part of the following procedures: 

- PGW Initiated EPS Bearer Modification 

- Execution part of MS -Initiated EPS Bearer Modification 

- SGSN-Initiated EPS Bearer Modification Procedure using S4 

and on the S2a/S2b interface by the PGW to the TWAN/ePDG as part of the following procedures: 

- PGW Initiated Bearer Modification 

- HSS Initiated Subscribed QoS Modification 

For PMIP based S5/S8, the Update Bearer Request shall be sent on the S 1 1 interface by the SGW to the MME and on 
the S4 interface by the SGW to the SGSN. 

Table 7.2.15-1 specifies the presence requirements and the conditions of the lEs in the message. 
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Table 7.2.15-1: Information Elements in an Update Bearer Request 



Information 


P 


Condition / Comment 


IE Type 


ins. 


elements 










Bearer Contexts 


M 


This IE shall contain contexts related to bearers that need 
QoS/TFT modification. Several lEs with this type and 
instance values shall be included as necessary to 
represent a list of Bearers. 

If there is no OoS/TFT modification, only one IE with this 
type and instance value shall be included. 


Bearer Context 





Procedure 
Transaction Id (PTI) 


C 


If the request corresponds to UE requested bearer 
resource modification procedure or the UE requested 
bearer resource allocation procedure for an E-UTRAN (see 
NOTE 1) or MS initiated EPS bearer modification 
procedure, this IE shall be included. 
PTI shall be the same as the one used in the 
corresponding Bearer Resource Command 


PTI 





Protocol 

Configuration Options 
(PCO) 


C 


PGW shall include Protocol Configuration Options (PCO) 
IE on the S5/S8 interface, if available. 
If SGW receives this IE, SGW shall forward it to 
SGSN/MME on the S4/S1 1 interface. 


PCO 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 


APN-AMBR 


AMBR 





Change Reporting 
Action 


C 


This IE shall be included on the S5/S8 and S4/S1 1 
interfaces with the appropriate Action field If the location 
Change Reporting mechanism is to be started or stopped 
for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





CSG Information 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 


CSG Information 





Reporting Action 




interfaces with the appropriate Action field if the CSG Info 
reporting mechanism is to be started or stopped for this 

subscriber in the SGSN/MME. 


Reporting Action 




H(e)NB Information 


CO 


This IE shall be included on the S5/S8 and S4/S1 1 


H(e)NB 





Reporting 




interfaces with the appropriate Action field if H(e)NB 
information reporting is to be started or stopped for the 
PDN connection in the SGSN/MME. 


Information 
Reporting 




Indication flags 


CO 


This IE shall be included if any one of the applicable flags 
is set to 1 . 

Applicable flags are: 

Retrieve Location Indication: This flag shall be set 
to 1 in the PGW Initiated Bearer Modification 
procedure if the location information is requested. 


Indication 





PGW-FQ-CSID 


c 


This IE shall be included by PGW on the S5/S8 and 
S2a/S2b interfaces, and when received from S5/S8 be 
forwarded by SGW on S1 1 according to the requirements 
in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by SGW on S1 1 according to the 
requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


VS 


NOTE 1 : This message refers to the UE requested bearer resource allocation procedure and UE requested 
bearer resource modification procedures defined in 3GPP TS 24.301 [23], both are specified in 
3GPP TS 23.401 [3] in the clause "UE requested bearer resource modification". 



NOTE: In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure 
or UE Requested Bearer Resource Allocation Procedure for an E-UTRAN or MS initiated EPS bearer 
modification procedure, then there will be only one instance of the Bearer Contexts IE in the Update 
Bearer Request. 
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Table 7.2.15-2: Bearer Context within Update Bearer Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


^^^^^^^^^^ = n 


:Qetet4 


■l^^^^^^^^pare Instanc^^^^^^^^^^^^^^^^^^H 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 


C 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces if message relates to Bearer 
Modification and TFT change. 


Bearer TFT 





Bearer Level QoS 


C 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces if QoS modification is requested 


Bearer QoS 





Bearer Flags 





Applicable flags: 

PPC (Prohibit Payload Compression): this flag may 
be set on the S5/S8 and S4/S1 1 interfaces. 

vSRVCC indicator: This IE may be included by the 
PGW on the S5/S8 interface according to 3GPP 
TS 23.216 [43]. When received from S5/S8, SGW 
shall forward on the S1 1 interface. 


Bearer Flags 





Protocol 

Configuration Options 
(PCO) 


CO 


PGW shall include Protocol Configuration Options (PCO) 
IE on the S5/S8 interface, if available. This bearer level IE 
takes precedence over the PCO IE in the message body if 
they both exist. If SGW receives this IE, SGW shall fonward 
it to SGSN/MME on the S4/S1 1 interface. 


PCO 






7.2.16 Update Bearer Response 

An Update Bearer Response shall be sent from a MME/SGSN to a SGW and forwarded to the PGW, and from 
TWAN/ePDG to the PGW as a response to an Update Bearer Request message. 

Table 7.2.16-1 specifies the presence requirements and the conditions of the lEs in the message. 

Cause IE indicates if an EPS bearer has been modified in the MME/SGSN/TWAN/ePDG or not. The EPS Bearer has 

not been modified in the MME/SGSN/TWAN/ePDG if the Cause IE value differs from "Request accepted" or "Request 
accepted partially". Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially" 

"Context not found" 

"Semantic error in the TFT operation". 

" Syntactic error in the TFT operation" . 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filter(s)". 

- "Denied in RAT". 

- "UErefiises". 

- "Unable to page UE". 
"UE not responding". 

"Unable to page UE due to Suspension". 
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Table 7.2.16-1: Information Elements in an Update Bearer Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Bearer Contexts 


M 


This IE shall contain contexts related to bearers for which 
QoS/TFT modification was requested. Several lEs with this 
type and instance values shall be included as necessary to 
represent a list of Bearers 


Bearer Context 





Protocol 

Configuration Options 
(PCO) 


CO 


An MME/SGSN shall include the PCO IE if such 
information was received from the UE. 
If the SGW receives this IE, the SGW shall fonward it to 
PGW on the S5/S8 interface. 


PCO 





Recovery 


c 


This IE shall be included on the S5/S8, S4/S1 1 and 
S2a/S2b interfaces if contacting the peer for the first time 


Recovery 





I^I^E-FQ-CSID 


c 


This IE shall be included by MME on S1 1 and shall be 
forwarded by SGW on S5/S8 according to the 
requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by SGW on S5/S8 according to 
the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


ePDG-FQ-CSID 


c 


This IE shall be included by the ePDG on the S2b interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


2 


TWAN-FQ-CSID 


c 


This IE shall be included by the TWAN on the S2a 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 


3 


Indication Flags 





This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Direct Tunnel Flag: this flag may be included on 
the S4 interface if the Direct Tunnel is used. 


Indication 










This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 






UE Time Zone 


CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


UE Time Zone 





User Location 
Information (ULI) 


CO 


This IE shall be included by the MME on the S1 1 interface 
or by the SGSN on the S4 interface. The CGI/SAI shall be 
included by SGSN and the ECGI shall be included by 
MME. 


ULI 







CO 


The SGW shall forward this IE on the S5/S8 interface if it 
receives it from the MME/SGSN. 






Private Extension 





This IE may be sent on the S5/S8, S4/S1 1 and S2a/S2b 
interfaces. 


Private Extension 


vs 


Table 7.2.16-2: Bearer Context within Update Bearer Response 


Octet 1 


Bearer Context IE Type = 93 (decimal) 






^^^^^^^^ 




Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE Indicates if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 





S4-U SGSN F-TEID 


C 


This IE shall be included on the S4 interface when direct 
tunnel is not established. 


F-TEID 





S12 RNC F-TEID 


C 


This IE shall be included on the S4 interface when direct 
tunnel flag is set to 1 . 


F-TEID 


1 


Protocol 

Configuration Options 
(PCO) 


CO 


An MME/SGSN shall include the PCO IE if such 

information was received from the UE. 

If the SGW receives this IE, the SGW shall fonward it to 

PGW on the S5/S8 interface. 

This bearer level IE takes precedence over the PCO IE in 
the message body if they both exist. 


PCO 
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7.2.17 Delete Bearer Command and Failure Indication 
7.2.17.1 Delete Bearer Command 

A Delete Bearer Command message shall be sent on the S 11 interface by the MME to the SGW and on the S5/S8 
interface by the SGW to the PGW as a part of the eNodeB requested bearer release or MME-Initiated Dedicated Bearer 
Deactivation procedure. 

The message shall also be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interface by the SGW to 
the PGW as part of the MS and SGSN Initiated Bearer Deactivation procedure using S4. 



Table 7.2.17.1-1: Information Elements in Delete Bearer Command 



Information 

elements 


P 


Condition / Comment 


IE Type 


Ins. 


Bearer Contexts 


M 


This IE shall be used to indicate dedicated bearers. When 
used, at least one dedicated bearer shall be present. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


Bearer Context 





Private Extension 







Private Extension 


VS 


Table 7.2.17.1-2: Bearer Context within Delete Bearer Command 


Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 




Octet 4 


^^^^^H Spare and Instance fields ^^^^^^^^^^^^H 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Bearer Flags 


CO 


Applicable flags are: 

VB (Voice Bearer) indicator shall be set to 
indicate a voice bearer for PS-to-CS (v)SRVCC 
handover. 

Vind (vSRVCC indicator) indicator shall be set to 
indicate a video bearer for PS-to-CS vSRVCC 
handover. 


Bearer Flags 






7.2.17.2 Delete Bearer Failure Indication 

A Delete Bearer Failure Indication shall be sent on the S5/S8 interface by the PGW to the SGW and on the SIX 
interface by the SGW to the MME as part of failure of eNodeB requested bearer release or MME Initiated Dedicated 
Bearer Deactivation procedure. 

The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
the SGSN as part of failure of MS and SGSN Initiated Bearer Deactivation procedure using S4. 

This message shall be sent back if none of the bearers (not even a single one) included in the Delete Bearer Command 
message could be deleted. 

The Cause IE indicates that the EPS bearer has not been deleted in the PGW. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 
"Context not found" 
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Table 7.2.17.2-1: Information Elements in a Delete Bearer Failure Indication 



Information 
elements 


n 
r 


Condition / Comment 


ic Type 


ins. 


Cause 


M 




Cause 





Bearer Context 


IVI 


This IE shall contain the list of failed bearers. See 
subclause 6.1 .1 "Presence requirements of Information 

Elements". 


Bearer Context 





Recovery 


C 


This IE shall be included If contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 


Table 7.2.17.2-2: Bearer Context within Delete Bearer Failure Indication 


Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


^^^^^B Spare and Instance fields ^^^^^^^^B 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 


See subclause 6.1.1 "Presence requirements of 
Information Elements". 


EBI 





Cause 


M 


This IE shall indicate the reason of the unsuccessful 
handling of the bearer. 


Cause 






7.2.18 Create liKjirect Data Forwar(jing Tunnel Request 

The Create Indirect Data Forwarding Tunnel Request message shall be sent on the S11/S4 interface by the MME/SGSN 
to the SGW as part of the Handover procedures. 

Table 7.2.18-1 specifies the presence requirements and the conditions of the lEs in the message. 
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Table 7.2.18-1: Information Elements in a Create Indirect Data Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


C 


This IE shall be included by the MME/SGSN if the SGW 
that the MME/SGSN selects for indirect data forwarding is 
different from the SGW already in use for the UE as the 
anchor point except for the case: 

- If the UE is emergency attached and the UE is 
UlCCIess 

When the IMSI is included in the message, it is not used as 
an identifier 

- if UE is emergency attached but IMSI is not 
authenticated. 

See N0TE1 . 


IMSI 





ME Identity (MEI) 


C 


This IE shall be included by the MME/SGSN if the SGW 
that the MME/SGSN selects for indirect data forwarding is 
different from the SGW already in use for the UE as the 
anchor point and if one of the following condition satisfies: 

- If the UE is emergency attached and the UE is 
UlCCIess 

- If the UE is emergency attached and the IMSI is not 
authenticated 


MEI 





Indication Flags 


CO 


This IE shall be included if any one of the applicable flags 
is set to 1 . 

Applicable flags are: 

Unauthenticated IMSI: This flag shall be set to 1 if 
the IMSI present in the message is not 
authenticated and is for an emergency attached 
UE. 


Indication 





Sender F-TEID for 
Control Plane 


c 


This IE shall be included by the MME/SGSN if the SGW 
that the MME/SGSN selects for indirect data fonwarding is 
different from the SGW already in use for the UE as the 
anchor point. 
See N0TE1. 


F-TEID 





Bearer Contexts 


M 


Several lEs with this type and instance value may be 
included as necessary to represent a list of Bearers 


Bearer Context 





Recovery 


CO 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 


NOTE 1 : Tlie SGW which is hosting the UE's bearer(s) is considered as the (local) anchor point. Unlil<e the 
PGW, the SGW may change due to mobility between eNodeBs, or E-UTRAN and GERAN/UTRAN 
supported with S4 based architecture. In these cases the new SGW where the UE's bearer(s) are 
moved, becomes the new local anchor point. A source MME/SGSN may select an SGW for indirect 
data forwarding which is different than the source (anchor) SGW. Similarly, a target MME/SGSN may 
select an SGW for indirect data forwarding which is different than the target (anchor) SGW. 
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Table 7.2.18-2: Bearer Context within Create Indirect Data Forwarding Tunnel Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


= n 


QeMA 


^^^^^^^^^pare Instanci^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





eNodeB F-TEID for 
DL data forwarding 


C 


Target eNodeB F-TEID. 

Tfiis IE shall be present in the message sent from the 
target MME to the SGW selected by the target MME for 
indirect data forwarding, or shall be included in the 
message sent from the source SGSN/MME to the SGW 
selected by the source MME for indirect data forwarding if 
the eNodeB F-TEID for DL data forwarding is included in 
the Fonward Relocation Response message. 


F-TEID 





SGW F-TEID for DL 
data forwarding 


C 


Target SGW F-TEID 

This IE shall be present in the message sent from the 
source MME/SGSN to the SGW selected by the source 

MME for indirect data forwarding if SGW F-TEID for DL 
data forwarding is included in the Forward Relocation 
Response message. This F-TEID is assigned by the SGW 
that the target MME/SGSN selects for indirect data 
forwarding. 


F-TEID 


1 


SGSN F-TEID for DL 
data forwarding 


C 


Target SGSN F-TEID 

This IE shall be present in the message sent from the 
target SGSN to the SGW selected by the target SGSN for 
indirect data forwarding in E-UTRAN to GERAN/UTRAN 
inter RAT handover with SGW relocation procedure, or 
shall be included in the message sent from the source 
MME to the SGW selected by the source MME for indirect 
data forwarding if the SGSN F-TEID for DL data forwarding 
is included in the Forwarding Relocation Response 
message. 


F-TEID 


2 




CO 


This IE shall also be present in the message sent from the 
source MME to the SGW selected by the source MME for 
indirect data forwarding if the SGSN Address for User 
Traffic and the Tunnel Endpoint Identifier Data II are 
included in the GTPv1 Forward Relocation Response 
message as specified in D.3.7 of 3GPP TS 23.401 [3]. 






RNC F-TEID for DL 


C 


Target RNC F-TEID 


F-TEID 


3 


data forwarding 




This IE shall be present in the message sent from the 
target SGSN to the SGW selected by the target SGSN for 
indirect data forwarding in E-UTRAN to UTRAN inter RAT 
handover with SGW relocation procedure, or shall be 

included in the message sent from the source MME to the 
SGW selected by the source MME for indirect data 
forwarding if the RNC F-TEID for DL data forwarding is 
included in the Forwarding Relocation Response message. 








CO 


This IE shall also be present in the message sent from the 

source MME to the SGW selected by the source MME for 
indirect data forwarding if the RNC IP address and TEID 
are included in the RAB Setup Information and/or the 
Additional RAB Setup Information in the GTPv1 
Forwarding Relocation Response message as specified in 
D.3.3 of 3GPP TS 23.401 [3]. 






eNodeB F-TEID for 





Target eNodeB F-TEID. 


F-TEID 


4 


UL data forwarding 




If available this IE may be present in the message, which is 
sent during the intra-EUTRAN HO from the target MME to 
the SGW selected by the target MME for indirect data 
forwarding, or may be included in the message sent from 
the source MME to the SGW selected by the source MME 
for indirect data fonwarding if the eNodeB F-TEID for data 
UL forwarding is included in the Forward Relocation 
Response message. 






SGW F-TEID for UL 
data forwarding 





Target SGW F-TEID 

If available this IE may be present in the message, which is 
sent during the intra-EUTRAN HO from the source MME to 


F-TEID 


5 
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the SGW selected by the source MME for indirect data 
forwarding if SGW F-TEID for UL data forwarding is 
included in the Forward Relocation Response message. 
This F-TEID is assigned by the SGW that the target MME 
selects for indirect data forwarding. 







7.2.19 Create Indirect Data Forwarding Tunnel Response 

A Create Indirect Data Forwarding Tunnel Response message shall be sent by the SGW to the MME/SGSN as a 
response to a Create Indirect Data Forwarding Tunnel Request message. 

Table 7.2.19-1 specifies the presence requirements and the conditions of the lEs in the message. 

The Cause value indicates if the Indirect Data Forwarding Tunnels has been created in the SGW or not. No Indirect 
Data Forwarding Turmels have been created in the SGW if the Cause differs from "Request accepted" or "Request 
accepted partially". Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially" . 

"Data forwarding not supported" . 

"Context not found". 



Table 7.2.19-1: Information Elements in a Create Indirect Data Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Sender F-TEID for 
Control Plane 


C 


This IE shall be included by an SGW if the SGW receives a 
Sender F-TEID for Control Plane IE from an MME/SGSN in 
a Create Indirect Data Forwarding Tunnel Request 
message. 

See also NOTE 1 in Table 7.2.1 8-1 . 


F-TEID 





Bearer Contexts 


M 


Several lEs with this type and instance value may be 
included as necessary to represent a list of Bearers 


Bearer Context 





Recovery 


CO 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





Private Extension 







Private Extension 


vs 
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Table 7.2.19-2: Bearer Context within Create Indirect Data Forwarding Tunnel Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 




:Q©tSt4 


^^^^^^H^pare and.lnstanc^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the tunnel setup was successful, 
and if not, gives information on the reason. 


Cause 





S1-U SGW F-TEID 
for DL data 
forwarding 


C 


This IE shall be included in the response sent from the 
SGW selected by the source MME for indirect data 
forwarding to the source MME. See NOTE 3. 


F-TEID 





S12SGW F-TEID for 
DL data forwarding 


C 


S12 usage only. 

This IE shall be included in the response sent from the 
SGW selected by the source SGSN for indirect data 
fonwarding to the source SGSN. See NOTE 3. 


F-TEID 


1 


S4-U SGW F-TEID 
for DL data 
fonwarding 


C 


S4-U usage only. 

This IE shall be included in the response sent from the 
SGW selected by the source SGSN for indirect data 
forwarding to the source SGSN. See NOTE 3. 


F-TEID 


2 


SGW F-TEID for DL 
data forwarding 


C 


This IE shall be included in the response message sent 
from the SGW selected by the target MME/SGSN for 
indirect data fonwarding to the target MME/SGSN. See 
NOTE 3. 


F-TEID 


3 


S1-U SGW F-TEID 
for UL data 
forwarding 





If available this IE may be included in the response sent 
during the intra-EUTRAN HO from the SGW selected by 
the source MME for indirect data forwarding to the source 
MME. See NOTE 4. 


F-TEID 


4 


SGW F-TEID for UL 
data forwarding 





If available this IE may be included in the response 
message sent during the intra-EUTRAN HO from the SGW 
selected by the target MME for indirect data fonwarding to 
the target MME. See NOTE 4. 


F-TEID 


5 


NOTE 1 : For DL data forwarding if the SGW does not have enough information to decide which of the F-TEID 

instance from S1-U, S12, S4-U and SGW to include in the message, it may include all of them. 
NOTE 2: For UL data forwarding if the SGW does not have enough information to decide which of the F-TEID 

instance from S1-U and SGW to include in the message, it may include both of them. 
NOTE 3: For DL data forwarding the SGW shall set the interface type in the F-TEID to 23, i.e 'SGW GTP-U 

interface for DL data forwarding' for S1-U/S4-U/S12/SGW. 
NOTE 4: For UL data forwarding the SGW shall set the interface type in the F-TEID to 28, i.e 'SGW GTP-U 

interface for UL data fonwarding' for SI -U/SGW. 



7.2.20 Void 

7.2.21 Release Access Bearers Request 

The Release Access Bearers Request message shall sent on the S 11 interface by the MME to the SGW as part of the SI 
release procedure. 

The message shall also be sent on the S4 interface by the SGSN to the SGW as part of the procedures: 

- RAB release using S4 
lu Release using S4 

- READY to STANDBY transition within the network 
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Table 7.2.21-1: Information Element in Release Access Bearers Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


List of RABs 





Shall be present on S4 interface when this message is 
used to release a subset of all active RABs according to 
the RAB release procedure. 

Several lEs with this type and instance values shall be 
included as necessary to represent a list of RABs to be 
released. 


EBI 





Originating Node 


GO 


This IE shall be sent on S1 1 interface, if ISR is active in the 
MME. 

This IE shall be sent on S4 interface, if ISR is active in the 
SGSN 

See NOTE 1 . 


Node Type 





Private Extension 







Private Extension 


vs 


NOTE 1 : If SGW has the S1 -U F-TEIDs for the UE, but the Originating Node IE contains value "SGSN", then 
the SGW shall not release the user plane and shall send a positive response to the SGSN. 


If SGW has the S12 RNC TElDs or S4-U SGSN TElDs for the UE, but the Originating Node IE 
contains value "MME", then the SGW shall not release the user plane and shall send a positive 
response to the MME. 





7.2.22 Release Access Bearers Response 

The Release Access Bearers Response message is sent on the SI 1 interface by the SGW to the MME as part of the SI 
release procedure. 

The message shall also be sent on the S4 interface by the SGW to the SGSN as part of the procedures: 
RAB release using S4 
lu Release using S4 

- READY to STANDBY transition within the network 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 
"Request accepted". 
"Request accepted partially". 

- "Context not found". 



Table 7.2.22-1: Information Element in Release Access Bearers Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 





This IE shall be included if contacting the peer for the first 
time 


Recovery 





Private Extension 







Private Extension 


VS 



7.2.23 Stop Paging Indication 

A Stop Paging Indication message shall be sent on the S11/S4 interface by the SGW to the MME/SGSN as a part of the 
network triggered service request procedure. 

Table 7.2.23-1 specifies the presence of the lEs in the message. 
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Table 7.2.23-1 : Information Elements in a Stop Paging Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 







Private Extension 


VS 



7.2.24 Modify Access Bearers Request 

The direction of this message shall be from MME to SGW (see Table 6.1-1). 

If both the SGW and the MME support the MABR feature (see subclause 8.83), an MME may send a Modify Access 
Bearer Request message on the S 11 interface to an SGW as part of the following procedures: 

UE triggered Service Request if there is no suspended bearer for that UE, 

- S 1 -based Handover without SGW relocation, 

- X2-based handover without SGW relocation, 

- Inter-MME E-UTRAN Tracking Area Update without SGW Change; 
if all the following conditions are fulfilled: 

the RAT type has not changed; 

the Serving Network has not changed; 

the MME does not need to report a H(e)NB local IP address and UDP port number information change; 

the MME does not need to send UE's location and/or User CSG information or/and UE Time Zone to the PDN 
GW; 

the MME does not need to send an MME-FQ-CSID as per the requirements specified in 3GPP TS 23.007 [17]; 

ISR is not activated, if the Modify Access Bearers Request is sent as part of a UE triggered Service Request; 

ISR was not activated in the old MME which is indicated by the ISRAU fiag in the Context Response, if the 
Modify Access Bearers Request is sent as part of an Inter-MME E-UTRAN Tracking Area Update without 
SGW change. 

The Modify Access Bearers Request message may modify Sl-U bearers of all the PDN connections of the UE. 
Support of this message is optional for the MME and SGW. 
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Table 7.2.24-1 : Information Elements in a Modify Access Bearers Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Indication Flags 


C 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags are: 

ISRAI: This flag shall be set to 1 if ISR is 
established between the MME and the S4 SGSN 
for an SI -based Handover without SGW relocation 
and for an X2-based Handover without SGW 
relocation. 

Change F-TEID support Indication: This flag shall 
be set to 1 for an IDLE state UE initiated TAU 
procedure to allow the SGW changing the GTP-U 
F-TEID. 


Indication 





Sender F-TEID for 
Control Plane 


C 


The new MME shall include this IE on the S1 1 interface for 
a TAU/Handover with MME change and without any SGW 
change. 

If the SGW receives this IE and if it finds that its value is 
the same as the earlier received value of this IE for this 
UE, it should interpret this to mean that the MME has not 
changed. 


F-TEID 





Delay Downlink 
Packet Notification 

Request 


c 


This IE shall be sent for a UE triggered Service Request. 


Delay Value 





Bearer Contexts to be 
modified 


c 


Several lEs with the same type and instance value may be 
included as necessary to represent a list of Bearers to be 
modified. 


Bearer Context 





Bearer Contexts to be 
removed 


c 


This IE shall be included for the TAU/Handover and 
Service Request procedures where any of the bearers 
existing before the TAU/Handover procedure and Service 

Request procedures will be deactivated as consequence of 
the TAU/Handover procedure and Service Request 
procedures. 

For the Service Request procedure, all unaccepted 
bearers for this UE shall be included. 
For each of those bearers, an IE with the same type and 
instance value, shall be included. 


Bearer Context 


1 


Recovery 


c 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 



ETSI 



3GPP TS 29.274 version 1 1 .5.0 Release 1 1 97 ETSI TS 1 29 274 V1 1 .5.0 (201 3-01 ) 



Table 7.2.24-2: Bearer Context to be modified witliin lUlodify Access Bearers Request 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 




Ctetete* 


■^^^^^^^^^pare Instanci^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





S1-U eNodeB F-TEID 


C 


This IE shall be sent for 

a UE triggered Service Request 

S1 -based Handover without SGW relocation 

X2-based handover without SGW relocation 

in S1 -U GTP-U tunnel setup procedure during an 
Inter-MME E-UTRAN Tracking Area Update 
without SGW Change procedure (see 3GPP TS 
24.301 [23]). 

If an MME is aware that the eNodeB supports both IP 
address types, the MME shall send both IP addresses 
within an F-TEID IE. If only one IP address is included, 
then the SGW shall assume that the eNodeB does not 
support the other IP address type. 


F-TEID 





Table 7.2.24-3: Bearer Context to be removed within IVIodify Access Bearers Request 


Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 






7.2.25 Modify Access Bearers Response 

If an SGW supports the MABR feature (see subclause 8.83), the SGW shall send a Modify Access Bearers Response 
message on the SI 1 interface to an MME as a response to a Modify Access Bearers Request message. 

If handling of all default bearers to be modified fails, then Cause at the message level shall be a failure cause. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially". 

- "Context not found". 
"Service not supported". 
"Modifications not limited to Sl-U bearers" 

The SGW shall send the cause value "Modifications not limited to Sl-U bearers" if 

it can not serve the MME Request without corresponding S5/S8 signalling, or without corresponding Gxc 
signalling when PMIP is used over the S5/S8 interface, or 

- if there are suspended non-GBR bearers for that UE in the SGW (NOTE 3). 

Upon receipt of that cause value, the MME shall repeat its request using Modify Bearer Request message per PDN 
connection. 
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NOTE 1 : This cause value is introduced for forward compatibility between an MME implementing this version of 
the specification and an SGW implementing a more recent version requiring the SGW to send S5/S8 
signalling. 

NOTE 2: During an Inter-MME Intra-SGW handover/TAU, if the SGW, PGW and the old MME support the partial 
failure handling feature but the new MME doesn't, the SGW needs to inform the PGW about the change 
of FQ-CSID (see subclause 16.2.5 of 3GPP TS 23.007 [17]). If the SGW receives a Modify Access 
Bearers Request from the new MME, it can force the MME to send individual Modify Bearer Request 
message per PDN connection by returning the cause value "Modifications not limited to Sl-U bearers". 

NOTE 3: There may be some suspended non-GBR bearers in the SGW during an Inter-MME Intra-SGW Tracking 
Area Update without SGW Change when the UE is coming back to E-UTRAN via a different MME than 
the MME serving the UE before the CSFB or SRVCC call. 



Table 7.2.25-1 : Information Elements in a IVIodify Access Bearers Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Bearer Contexts 
modified 


C 


EPS bearers corresponding to Bearer Contexts to be 
modified that were sent in Modify Access Bearers Request 
message. Several lEs with the same type and instance 
value may be included as necessary to represent a list of 
the Bearers which are modified. 


Bearer Context 





Bearer Contexts 
marl<ed for removal 


C 


EPS bearers corresponding to Bearer Contexts to be 
removed that were sent in the Modify Access Bearers 
Request message. Shall be included if request message 
contained Bearer Contexts to be removed. 
For each of those bearers an IE with the same type and 
instance value shall be included. 


Bearer Context 


1 


Recovery 


c 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 


Table 7.2.25-2: Bearer Context modified within lUlodify Access Bearers Response 


Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octets 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 





S1 SGW F-TEID 


M 


The SGW may change the GTP-U F-TEID value if the 
'Change F-TEID support Indication' flag was set to 1 in the 
Modify Access Bearers Request. Otherwise, the SGW 
shall return the currently allocated GTP-U F-TEID value. 
See NOTE 1 . 


F-TEID 





NOTE 1 : The SGW shall not change its F-TEID for a given interface during the Handover, Service Request. 

During Handover and Service Request the target eNodeB may use a different IP type than the one 
used by the source eNodeB. In order to support such a scenario, the SGW F-TEID should contain 
both an IPv4 address and an IPv6 address (see also subclause 8.22 "F-TEID"). 
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Table 7.2.25-3: Bearer Context marked for removal within Modify Access Bearers Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 




£teteM. 


^I^^^^^^H^pare jnstan^^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 






7.3 Mobility IVIanagement IVIessages 
7.3.1 Forward Relocation Request 

A Forward Relocation Request message shall be sent from the source MME to the target MME over SIO interface as 
part of SI -based handover relocation procedure from the source MME to the target SGSN, or from the source SGSN to 
the target MME over S3 interface as part of Inter RAT handover and combined hard handover and SRNS relocation 
procedures, or from source SGSN to the target SGSN over S 16 interface as part of SRNS Relocation and PS handover 
procedures. 

A Forward Relocation Request message shall also be sent from the source MME to the target SGSN over S3 interface 
as part of SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support procedures and from source SGSN 
to the target SGSN over S16 interface as part of SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO 
support. 

Forward Relocation procedure across SIO interface (when Kasme is taken into use) shall be performed according to the 
Rules on Concurrent Running of Security Procedures, which are specified in 3GPP TS 33.401 [12]. 

Table 7.3.1-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.1-1: Information Elements in a Forward Relocation Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


IMSI 


C 


Tfie IMSI shall be included in the message except for the 
case: 

If the UE is emergency attached and the UE is 
UlCCIess. 

The IMSI shall be included in the message but not used as 
an identifier 

if UE is emergency attached but IMSI is not 

authenticated. 


IMSI 





Sender's F-TEID for 
Control Plane 


M 




F-TEID 





MME/SGSN UE EPS 
PDN Connections 


C 


This IE shall be present, except over the S16 interface if 
there is no active PDP context and the source and target 
SGSNs supports SRNS relocation w/o PDN connection 
over GTPv2 (see NOTE 2). Several lEs with this type and 
instance values shall be included as necessary to 
represent a list of PDN Connections 


PDN Connection 





SGW S11/S4 IP 
Address and TEID for 
Control Plane 


C 


This IE shall be present, except over the S1 6 interface if 
there is no active PDP context and the source and target 
SGSNs supports SRNS relocation w/o PDN connection 
over GTPv2 (see NOTE 2). 


F-TEID 


1 


SGW node name 


c 


This IE identifies the SGW that was used by the old 
MME/S4-SGSN. It shall be included by the source 
MME/S4-SGSN, except over the S1 6 interface if there is 
no active PDP context and the source and target SGSNs 
supports SRNS relocation w/o PDN connection over 
GTPv2 (see NOTE 2). 


FQDN 





IVII\4E/SGSN UE MM 

Context 


M 




MM Context 





Indication Flags 


c 


This IE shall be included if any of the flags are set to 1 . 

Direct Forwarding Indication: This flag shall be set 
to 1 if direct forwarding is supported in the S1 
based handover procedure. This flag shall not be 
set to 1 if the message is used for other handover 
procedures. 

Idle mode Signalling Reduction Supported 
Indication flag: This flag shall be set to 1 if the 
source MME/SGSN and associated SGW are 
capable to establish ISR for the UE. 

Unauthenticated IMSI: This flag shall be set to 1 if 
the IMSI present in the message is not 
authenticated and is for an emergency attached 
UE. 

Change Reporting support indication flag: This 
flag shall be set to 1 if the Source S4-SGSN/MME 
supports Location Change Reporting mechanism. 
See N0TE1 . See NOTE 3. 

CSG Change Reporting Support Indication flag: 
This flag shall be set to 1 if the Source S4- 
SGSN/MME supports CSG Information Change 
Reporting mechanism. See N0TE1. See NOTE 3. 

Management Based MDT allowed flag: This flag 
shall be set to 1 for the S1 based inter-MME 
handover procedure over the S10 interface, if 
Management Based Minimization of Drive Tests 
(MDT) is allowed. See 3GPP TS 36.413 [10] and 
3GPPTS 32.422 [18]. 


Indication 






ETSI 



3GPP TS 29.274 version 1 1 .5.0 Release 1 1 



101 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



E-UTRAN 


C 


This IE shall be included to contain the "Source to Target 


F-Container 





Transparent 
Container 




Transparent Container", if the message is used for 
UTRAN/GERAN to E-UTRAN inter RAT handover 
procedure, E-UTRAN intra RAT handover procedure and 
3G SGSN to MME combined hard handover and SRNS 
relocation procedure. The Container Type shall be set to 3. 






UTRAN Transparent 
Container 


C 


This IE shall be included to contain the "Source to Target 
Transparent Container", if the message is used for PS 
handover to UTRAN lu mode procedures, SRNS relocation 
procedure and E-TURAN to UTRAN inter RAT handover 
procedure. The Container Type shall be set to 1 . 


F-Container 


1 


BSS Container 


C 


This IE shall be included to contain the "Source BSS to 
Target BSS Transparent Container" if the message is used 
for PS handover to GERAN A/Gb mode and E-UTRAN to 
GERAN A/Gb mode inter RAT handover procedure. The 
Container Type shall be set to 2. 


F-Container 


2 


Target Identification 


C 


This IE shall be included if the message is used for SRNS 
relocation procedure and handover to UTRAN/E-UTRAN 
procedures. 


Target 

Identification 





HRPD access node 


C 


This IE shall be included only if the HRPD pre registration 


IP-Address 





S101 IP address 




was performed at the source MME 






1xlWS S102 IP 


C 


This IE shall be included only if the 1xRTT CS fallback pre 


IP-Address 


1 


address 




registration was performed at the source MME 






S1-AP Cause 


C 


This IE is the information received from the source 
eNodeB, and the source MME shall include this IE in the 
message. Refer to the 3GPP TS 29.01 [42] for the 
mapping of cause values between S1 AP, RANAP and 
BSSGP. 


F-Cause 





RANAP Cause 


C 


This IE is the information from the source RNC, the source 
SGSN shall include this IE in the message. Refer to the 
3GPP TS 29.01 [42] for the mapping of cause values 

between S1AP, RANAP and BSSGP. 


F-Cause 


1 


BSSGP Cause 


C 


This IE is the information received from source BSS, and 
the source SGSN shall include this IE in the message. 
Refer to the 3GPP TS 29.01 [42] for the mapping of 
cause values between SI AP, RANAP and BSSGP. 


F-Cause 


2 


Source Identification 


C 


This IE shall be included on the SI 6 interface if the 
message is used for PS handover from GERAN/UTRAN to 
GERAN A/Gb mode. 


Source 
Identification 





Selected PLMN ID 


C 


The old MME/SGSN shall include this IE if the selected 
PLMN identity is available. The Selected PLMN ID IE 

indicates the target core network operator selected for the 
UE in a shared network. 


PLMN ID 





Recovery 


C 


If contacting the peer for the first time 


Recovery 





Trace Information 


c 


This IE shall be included when session trace is active for 
this IMSI/IMEI. 


Trace Information 





Subscribed RFSP 
Index 


CO 


This IE shall be included during inter-MME/SGSN mobility 
procedures, if the source MME/SGSN receives it from an 
HSS. 


RFSP Index 





RFSP Index in Use 


CO 


This IE shall be included only during inter-MME/SGSN 
mobility procedures, if the source MME/SGSN supports the 

feature. 


RFSP Index 


1 


CSG ID 


CO 


This IE shall be included on the S3/S10/S1 6 interfaces if 
the source MME/SGSN receives it from the source 
eNodeB/RNC. 


CSG ID 





CSG Membership 
Indication 


CO 


This IE shall be included on the S3/S10/S1 6 interfaces by 
the source MME/SGSN if the CSG access mode is 
received from the source eNodeB/RNC and indicates the 
target cell is a hybrid cell, or if the UE has emergency 
bearer(s) and the target cell is a CSG cell. 


CMI 





UE Time Zone 


CO 


When available, this IE shall be included by the source 
MME/S4-SGSN. 


UE Time Zone 





Serving Network 


CO 


This IE shall be included to indicate the current Serving 
Network. 


Serving Network 





MME/S4-SGSN LDN 





This IE is optionally sent by the MME/S4-SGSN to the peer 
MME/S4-SGSN on the S3/S10/S16 interfaces (see 3GPP 
TS 32.423 [44]), when communicating the LDN to the peer 
node for the first time. 


Local 
Distinguished 
Name (LDN) 
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Additional MM 
context for SRVCC 


CO 


This IE shall be sent by the source MME/S4-SGSN to the 
target MME/S4-SGSN on the S3/S10/S16 interfaces if MS 
Classmark2, MS Classmark3 and the Supported Codec 
are available in the source MME/S4-SGSN. 


Additional MM 
context for 
SRVCC 





Additional flags for 
SRVCC 


CO 


This IE shall be included if any one of the applicable flags 

needs to be forwarded. 

Applicable flags: 

ICS Indicator: This IE shall be sent by the source 
MME/S4-SGSN to the target MME/S4-SGSN on 
the S3/S10/S16 interfaces if ICS Indicator is 
available in the source MME/S4-SGSN. 

vSRVCC flag: This IE shall be sent by the source 
MME to the target MME on the S10 interface if 
vSRVCC flag is available in the source MME. 


Additional flags 
for SRVCC 





STN-SR 


CO 


This IE shall be sent by the source MME/S4-SGSN to the 
target MME/S4-SGSN on the S3/S10/S16 interfaces if 
STN-SR is available in the source MME/S4-SGSN. 


STN-SR 





C-MSISDN 


CO 


This IE shall be sent by the source MME/S4-SGSN to the 
target MME/S4-SGSN on the S3/S10/S16 interfaces if C- 
MSISDN is available in the source MME/S4-SGSN. The C- 
MSISDN is defined in 3GPP TS 23.003 [2]. 


MSISDN 





MDT Configuration 


CO 


This IE shall be sent by the source MME to the target MME 
on the SI interface for the SI -based handover relocation 
procedure, if the Job Type indicates Immediate MDT. See 
3GPP TS 32.422 [18] subclause 4.2.6. 


MDT 
Configuration 





SGSN node name 


CO 


This IE shall be sent by the source SGSN on the S3 
interface if both source SGSN and associated SGW 
support ISR. See NOTE 4. 


FQDN 


1 


MME node name 


CO 


This IE shall be sent by the source MME on the S3 
interface if both source MME and associated SGW support 
ISR. See NOTE 4. 


FQDN 


2 


Private Extension 







Private Extension 


VS 


NOTE 1 : 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1) 

defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In 
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change 
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change 
Reporting Support Indication. 

NOTE 2: GTPv2 shall be used for SRNS relocation w/o PDN connection if all the S4-SGSNs (between which 
SRNS relocation can take place) support this optional GTPv2 procedure. Otherwise GTPvl shall be 
used for that procedure (see subclause 7.10). The S4-SGSN can know by local configuration 
whether all peer S4-SGSNs support this procedure. 

NOTE 3: The receiver shall ignore the per UE Change Reporting Support Indication and CSG Change 

Reporting Support Indication flags, as included within the Indication Flags IE above, if these flags are 
included per PDN connection i.e. within the Indication Flags IE of the MME/SGSN UE EPS PDN 
Connections IE. 

NOTE 4: According to the 3GPP TS 23.401 [3], during an inter-RAT handover procedure for a UE with ISR 

activated, the source MME/SGSN should select the ISR associated CN node for this UE as the target 
CN node for the inter RAT HO when the ISR associated CN node can serve the target access. This 
parameter is exchanged when ISR is being activated and used in the source MME/SGSN for this 
decision upon subsequent inter-RAT handover. 



The PDN Connection grouped IE shall be coded as depicted in Table 7.3.1-2. 
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Table 7.3.1-2: MME/SGSN UE EPS PDN Connections within Forward Relocation Request 



Octet 1 


PDN Connection IE Type = 109 (decimal) 


Octets 2 and 3 


n 


:0eM;4; 


^^^^^^ftSpare Instanc^^^^^^^^^^^^^^^^^^H 


Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


APN 


M 




APN 





APN Restriction 


C 


This IE denotes the restriction on the combination of types 
of APN for the APN associated with this EPS bearer 
Context. The target MME or SGSN determines the 
Maximum APN Restriction using the APN Restriction. 
If available, the source MME/S4SGSN shall include this IE. 


APN Restriction 





Selection IVlode 


CO 


When available, this IE shall be included by the source 
MME/S4-SGSN 


Selection Mode 





IPv4 Address 


c 


This IE shall not be included if no IPv4 Address is 
assigned. See NOTE 1 . 


IP Address 





IPv6 Address 


c 


This IE shall not be included if no IPv6 Address is 

assigned. 


IP Address 


1 


Linked EPS Bearer ID 


M 


This IE identifies the default bearer of the PDN 
Connection. 


EBI 





PGW S5/S8 IP 
Address for Control 
Plane or PMIP 


M 


This IE shall include the TEID in the GTP based S5/S8 
case and the GRE key in the PMIP based S5/S8 case. 


F-TEID 





PGW node name 


C 


This IE shall be included if the source MME or SGSN has 
the PGW FQDN. 


FQDN 





Bearer Contexts 


C 


Several lEs with this type and instance values may be 
included as necessary to represent a list of Bearers. 


Bearer Context 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 




AMBR 





Charging 
characteristics 


C 


This IE shall be present if charging characteristics was 
supplied by the HSS to the MME/SGSN as a part of 
subscription information. 


Charging 
characteristics 





Change Reporting 
Action 


C 


This IE shall be included whenever available at the source 
MME/SGSN. 


Change Reporting 
Action 





CSG Information 
Reporting Action 


CO 


This IE shall be included whenever available at the source 
MME/SGSN. 


CSG Information 
Reporting Action 





H(e)NB Information 
Reporting 


CO 


This IE shall be included whenever available at the source 
MME/SGSN. 


H(e)NB 
Information 
Reporting 





Indication Flags 


CO 


This IE shall be included if any of the flags are set to 1 . 

Change Reporting support indication flag: This 
flag shall be set to 1 if the Source S4-SGSN/MME 
supports Location Change Reporting mechanism 
and if the S4-SGSN/MME has indicated the 
support for the Location Change Reporting 
mechanism to the PGW, during the session 
establishment and/or modification procedures. 
See NOTE 2. 

CSG Change Reporting Support Indication flag: 
This flag shall be set to 1 if the Source S4- 
SGSN/MME supports CSG Information Change 
Reporting mechanism and if the S4-SGSN/MME 
has indicated the support for the CSG Informatoin 
Change Reporting to the PGW, during the 
session establishment and/or modification 
procedures. See NOTE 2. 


Indication 





Signalling Priority 
Indication 


CO 


The source SGSN/MME shall include this IE if the UE 

indicated low access priority when establishing the PDN 
connection. 


Signalling Priority 
Indication 





Change to Report 
Flags 


CO 


This IE shall be included by the SGSN if any one of the 

applicable flags is set to 1 . See NOTES. 

Applicable flags: 

Serving Network Change to Report: This flag shall 
be set to 1 if the source SGSN has detected a 
Serving Network change during a RAU procedure 


Change to Report 
Flags 
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without SGSN change but has not yet reported this 

change to the PGW. 

Time Zone Change to Report; This flag shall be set 
to 1 if the source SGSN has detected a UE Time 
Zone change during a RAU procedure without 
SGSN change but has not yet reported this change 
to the PGW. 



NOTE 1 : For deferred IPv4 address allocation, if the l\/IME/S4-SGSN receives the PDN address "0.0.0.0" from 
PGW during "eUTRAN Initial Attach", "POP Context Activation", "UE requested PDN Connectivity", 
then the IVIME/S4-SGSN shall include this IPv4 address "0.0.0.0". 

NOTE 2: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1 ) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1 ) 

defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In 
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change 
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change 
Reporting Support Indication. 

NOTE 3: When UE is camping on the 3G and performs a Service Request procedure, as specified in the 
subclause 6.12.1 of 3GPP TS 23.060 [35], if Service Type indicates Signalling, the signalling 
connection is established between the MS and the SGSN for sending upper-layer signalling 
messages, e.g. Activate PDP Context Request, but the resources for active PDP context(s) are not 
allocated, therefore the change of Serving Network or UE Time zone may not be reported to 

SGW/PGW for the existing PDP Contexts. 



The Bearer Context grouped IE shall be coded as depicted in Table 7.3.1-3. 



Table 7.3.1-3: Bearer Context within MME/SGSN UE EPS PDN Connections within Forward Relocation 

Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 








Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


EPS Bearer ID 


M 




EBI 





TFT 


C 


This IE shall be present If a TFT Is defined for this bearer. 


Bearer TFT 





SGW S1/S4/S12 IP 
Address and TEID for 
user plane 


M 




F-TEID 





PGW S5/S8 IP 
Address and TEID for 
user plane 


C 


This IE shall be present for GTP based S5/S8 


F-TEID 


1 


Bearer Level QoS 


M 




Bearer Level QoS 





BSS Container 


CO 


The MME/S4 SGSN shall include the Packet Flow ID, 
Radio Priority, SAPI, PS Handover XID parameters In the 
TAU/RAU/Handover procedure. If available. See Figure 
8.48-2. The Container Type shall be set to 2. 


F-Container 





Transaction Identifier 


c 


This IE shall be sent over S3/S10/S16 If the UE supports 
A/Gb and/or lu mode. 


Tl 





Bearer Flags 


CO 


Applicable flags: 

vSRVCC Indicator; This IE shall be sent by the 
source MME to the target MME on the S10 
interface if vSRVCC Indicator Is available In the 
source MME. 

ASI (Activity Status Indicator); the source S4- 
SGSN shall set this Indicator to 1 on the SI 6 
interface if the bearer context Is preserved In the 
CN without an associated RAB. 


Bearer Flags 
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7.3.2 Forward Relocation Response 

A Forward Relocation Response message shall be sent as a response to Forward Relocation Request during SI -based 
handover procedure, Inter RAT handover procedures, SRNS Relocation procedure and PS handover procedures. 

Table 7.3.2-1 specifies the presence requirements and conditions of the lEs in the message. 

Cause IE indicates if the relocation has been accepted, or not. The relocation has not been accepted by the target 
MME/SGSN if the Cause IE value differs from "Request accepted". Possible Cause values are specified in Table 8.4-1. 

Message specific cause values are: 

"Relocation failure". 
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Table 7.3.2-1 : Information Elements in a Forward Relocation Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


Cause 


M 




Cause 





Sender's F-TEID for 
Control Plane 


C 


If tlie Cause IE contains the value "Request accepted", the 
target MME/SGSN shall include this IE in Forward 

Relocation Response message. 


F-TEID 





Indication Flags 


C 


This IE shall be included if any of the flags are set to 1 . 
SGW Change Indication: 

- This flag shall be set to 1 if the target MME/SGSN 
has selected a new SGW. 


Indication 





List of Set-up Bearers 


c 


The list of set-up Bearers IE contains the EPS bearer 

Identifiers of the Bearers that were successfully allocated 
in the target system during a handover procedure. This IE 
shall be included if the source and target access type is 
EUTRAN and the Cause IE contains the value "Request 
accepted". 
See NOTE 1 . 

Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 





List of Set-up RABs 


c 


The list of set-up RABs IE contains the RAB Identifiers of 
the RABs that were successfully allocated in the target 
system. This IE shall be included if the Cause IE contains 
the value "Request accepted" and 

If the source access type is UTRAN and the 
target access type is E-UTRAN/UTRAN, 
If the source access type is E-UTRAN and the 
target access type is UTRAN, 
except over the S1 6 interface if the Forward Relocation 
Request did not include the MME/SGSN UE EPS PDN 
Connections IE. 
See NOTE 1 . 

Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 


1 


List of Set-up PRCs 





The list of set-up PFCs IE contains the Packet Flow 
Identifies of the PFCs that were successfully allocated in 
the target system during a PS handover to/from GERAN or 
inter RAT handover to/from GERAN. If the Cause IE 
contains the value "Request accepted", this IE may be 
included. 
See NOTE 1 . 

Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 


2 


S1-AP Cause 


c 


This IE is included if cause value is contained in S1 -AP 
message. Refer to the 3GPP TS 29.010 [42] for the 
mapping of cause values between S1AP, RANAP and 
BSSGP. 


F-Cause 





RANAP Cause 


c 


This IE is included if cause value is contained in RANAP 
message. Refer to the 3GPP TS 29.01 [42] for the 
mapping of cause values between S1AP, RANAP and 

BSSGP. 


F-Cause 


1 


BSSGP Cause 


c 


For handover to GERAN, if a cause value is received from 
the Target BSC, the BSSGP Cause IE shall be included 
and shall be set to the cause value received from the 
target BSC. Refer to the 3GPP TS 29.01 [42] for the 
mapping of cause values between SI AP, RANAP and 
BSSGP. 


F-Cause 


2 


E-UTRAN 

Transparent 

Container 


c 


This IE shall be included to contain the "Target to Source 
Transparent Container" during a handover to E-UTRAN. If 
the Cause IE contains the value "Request accepted". The 
Container Type shall be set to 3. 


F-Container 





UTRAN Transparent 
Container 


c 


This IE shall be included to contain the "Target to Source 

Transparent Container" during a handover to UTRAN. If 
the Cause IE contains the value "Request accepted". The 
Container Type shall be set to 1 . 


F-Container 


1 


BSS Container 


c 


This IE shall be included to contain the Target BSS to 


F-Container 


2 
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Source BSS Transparent Container during a handover to 
GERAN. If the Cause IE contains the value "Request 
accepted". The Container Type shall be set to 2 






MME/S4-SGSN LDN 





This IE is optionally sent by the MME/S4-SGSN to the peer 
MME/S4-SGSN on the S3/S10/S16 interfaces (see 3GPP 
TS 32.423 [44]), when communicating the LDN to the peer 
node for the first time. 


Local 
Distinguished 
Name (LDN) 





SGSN node name 


CO 


This IE shall be sent by the target SGSN on the S3 
interface if both target SGSN and associated SGW support 
ISR. See NOTE 2. 


FQDN 





MME node name 


CO 


This IE shall be sent by the target MME on the S3 interface 
if both target MME and associated SGW support ISR. See 
NOTE 2. 


FQDN 


1 


Private Extension 







Private Extension 


vs 


NOTE 1 : In tine Forward Relocation Request message, the inclusion of "RAN Cause" indicates that the source 
access type is E-UTRAN. In the Forward Relocation Request message, the inclusion of "RANAP 
Cause" indicates that the source access type is UTRAN. In the Forward Relocation Request 
message, the inclusion of "BSSGP Cause" indicates that the source access type is GERAN. 

NOTE 2: According to the 3GPP TS 23.401 [3], during an inter-RAT handover procedure for a UE with ISR 

activated, the source MME/SGSN should select the ISR associated CN node for this UE as the target 
CN node for the inter RAT HO when the ISR associated CN node can serve the target access. This 
parameter is exchanged when ISR is being activated and used in the source MME/SGSN for this 
decision upon subsequent inter-RAT handover. 



Bearer Context IE in this message is specified in Table 7.3.2-2, the source system shall use this IE for data forwarding 
in handover. 

Table 7.3.2-2: Bearer Context 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 




Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


C 


This IE shall be included if the message is used for S1 - 
Based handover procedure. 

This IE shall be included if the message is used for SRNS 
relocation procedure and Inter RAT handover to/from lu 
mode procedures. 


EBI 





Packet Flow ID 


C 


This IE shall be included if the message is used for PS 
handover and Inter RAT handover to/from A/Gb mode 
procedures. 


Packet Flow ID 





eNodeB F-TEIDfor 
DL data forwarding 


c 


This IE shall be included for the message sent from the 
target MME, if the DL Transport Layer Address and DL 
GTP TEID are included in the "SAE Bearers Admitted List" 
of the S1AP: HANDOVER REOUEST ACKNOWLEDGE 
and direct forwarding or indirect forwarding without SGW 
change is applied. 


F-TEID 





eNodeB F-TEID for 
UL data fonwarding 





This IE may be included for the message sent from the 
target MME during the intra-EUTRAN HO, if the UL 
Transport Layer Address and UL GTP TEID are included in 
the "SAE Bearers Admitted List" of the S1 AP: HANDOVER 

REQUEST ACKNOWLEDGE and direct forwarding or 
indirect forwarding without SGW change is applied. 


F-TEID 


1 


SGW F-TEIDfor DL 
data forwarding 


c 


This SGW F-TEID shall be included when indirect data 
forwarding with SGW change is applied. 


F-TEID 


2 


RNC F-TEID for DL 
data fonwarding 


c 


This RNC F-TEID shall be included in the message sent 
from SGSN, if the target system decides using RNC F- 
TEID for data forwarding. 


F-TEID 


3 


SGSN F-TEID for DL 
data forwarding 


c 


This SGSN F-TEID shall be included in the message sent 
from SGSN, if the target system decides using SGSN F- 
TEID for data forwarding. 


F-TEID 


4 


SGW F-TEID for UL 
data fonwarding 





If available this SGW F-TEID may be included when 
indirect data fonwarding with SGW change is applied, 
during the intra-EUTRAN HO. 


F-TEID 


5 
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7.3.3 Forward Relocation Complete Notification 

A Forward Relocation Complete Notification message shall be sent to the source MME/SGSN to indicate the handover 
has been successfully finished. 

Table 7.3.3-1 specifies the presence requirements and conditions of the lEs in the message. 



Table 7.3.3-1 : Information Elements in a Forward Relocation Complete Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Indication Flags 


C 


This IE shall be included if any of the flags are set to 1 . 
Idle mode Signalling Reduction Activation Indication: This 
flag shall be set to 1 if the message is used for inter RAT 
handover and the UE has ISR capability. This flag is set to 
indicate to the source IVIIVIE/SGSN whether it shall 
maintain the UE's context and whether it shall activate iSR. 


Indication 





Private Extension 







Private Extension 


VS 



7.3.4 Forward Relocation Complete Acknowledge 

A Forward Relocation Complete Acknowledge message shall be sent as a response to Forward Relocation Complete 
Notification during inter eNodeB handover with MME relocation procedure, SRNS Relocation with SGSN change 
procedures using S4 or Inter RAT Handover with MME/S4 SGSN interaction procedures. 

Table 7.3.4-1 specifies the presence requirements and conditions of the lEs in the message. 

Possible Cause values are specified in Table 8.4-1. 



Table 7.3.4-1 : Information Elements in a Forward Relocation Complete Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 







Recovery 





Private Extension 







Private Extension 


VS 



7.3.5 Context Request 

The new MME/SGSN shall send the Context Request message to the old MME/SGSN on S3/S 16/S 10 interface as a 
part of TAU/RAU procedure and UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) SRVCC procedure to get the MM 
and EPS bearer Contexts for the UE. 

NOTE 1: During UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) SRVCC procedure as specified in 3GPP TS 
23.216 [43], the GUTl, RAl IE, P-TMSl IE and P-TMSI Signature IE, are not received directly from the 
UE but from the MSC Server over Sv interface. 

If the sending/new node is a MME, it shall include in the Context Request message: 

- the GUTl IE and Complete TAU Request Message IE, if the GUTI or the indication of mapped or native GUTI 
received from UE indicates the old node is a MME, as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. 

- the RAI IE and the P-TMSI IE, which are derived from the GUTI received from UE, and the P-TMSI Signature 
that was received intact from the UE, if the GUTI or the indication of mapped or native GUTI indicates the old 
node is an SGSN as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. 

If the sending/new node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Context 
Request message. If the receiving/old node is an MME, it shall construct GUTI according to the RAI IE, P-TMSI IE 
and P-TMSI Signature IE (see the mapping relationship between RAI, P-TMSI, P-TMSI signature and GUTI defined in 
3GPP TS23.003[2]), and find UE context via this GUTI. 
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The new MME differentiates the type of the old node as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. If the 
old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; if the old node is a MME, the 
new MME include GUTI IE and Complete TAU Request Message IE in the Context Request message. The Mapping 
between temporary and area identities is defined in 3GPP TS 23.003 [2]. 

The Target PLMN ID IE shall be used in old SGSN/MME in order to decide whether un-used authentication vectors to 
be distributed to new SGSN/MME or not. Distribution and use of authentication vectors between different serving 
network domains are specified in 3GPP TS 33.401 [12]. 

Table 7.3.5-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.5-1 : Information Elements in a Context Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


IMSI 


C 


IMSI shall be included if the UE has been successfully 
authenticated. 


IMSI 





GUTI 


C 


The New MME shall include this IE over S10 interface. 


GUTI 





CO 


This IE shall be included over S10 interface if available 
during UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) 
SRVCC procedure as specified in 3GPP TS 23.216 [43]. 


Routeing Area 
Identity(RAI) 


C 


This IE shall be included over S3/S16 interface, if the GUTI 
or the indication of mapped or native GUTI indicates the 
old node is an SGSN, the new MME maps this IE from 
GUTI. 


ULI for RAI 





CO 


This IE shall be included over S3/S16 interface if available 
during UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) 
SRVCC procedure as specified in 3GPP TS 23.216 [43]. 


Packet TMSI(P-TMSI) 


c 


This IE shall be included over S3/S16 interface. For the S3 
interface, if sent by the MME, this IE is derived by the MME 
from the GUTI received from the UE. 


P-TMSI 





CO 


This IE shall be included over S3/S16 interface if available 
during UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) 
SRVCC procedure as specified in 3GPP TS 23.216 [43]. 


P-TMSI Signature 


c 


This IE shall be included over S3/S16 interface if it is 

received from the UE. 


P-TMSI Signature 





CO 


This IE shall be included over S3/S16 interface if available 
during UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) 
SRVCC procedure as specified in 3GPP TS 23.216 [43]. 


Complete TAD 
request message 


c 


The new MME shall include this IE if available, and the old 
MME may use this IE for integrity check. See NOTE 3. 


Complete 
Request Message 





S3/S16/S10 Address 
and TElDfor Control 
Plane 


c 


This IE specifies the address and the TEID for control 
plane message which is chosen by the new MME/SGSN. 
In case of SGSN pool, the IPv4 or the IPv6 address field 
shall be set to the same value of the Source IP address of 
the IP packet carrying this message, and the relaying 
SGSN shall not change the content of this IE when 
sending it to the old SGSN. See NOTE 1 . 


F-TEID 





UDP Source Port 
Number 


c 


If an SGSN within the same SGSN pool as the old SGSN 
receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
parameter if this IE is not present and relay the message to 
the old SGSN. The old SGSN shall use this UDP port as 
the UDP destination port of the Context Response 
message. 


Port Number 





RAT Type 


c 


The RAT Type indicates the Radio Access Technology 
which is used in the new system. 


RAT Type 





Indication 





This IE shall be included if any one of the applicable flags 
is set to 1 . 

Applicable Flags are: 

- The MS Validated indicates that the new system 
has successfully authenticated the UE, or the new 
system has validated the integrity protection of the 
TAU request message. See NOTE 3. 


Indication 





Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise, the SGSN may include a Hop Counter with a 
value of max-1 , and may relay the message to the old 
SGSN. 


Hop Counter 





Target PLMN ID 


CO 


If available, this IE shall be included in order to allow old 
MME/SGSN to make a judgment whether un-used 
authentication vectors to be distributed or not. 


Serving Network 





MME/S4-SGSN LDN 





This IE is optionally sent by the MME/S4-SGSN to the peer 
MME/S4-SGSN on the S3/S10/S1 6 interfaces (see 3GPP 
TS 32.423 [44]), when communicating the LDN to the peer 
node for the first time. 


Local 
Distinguished 
Name (LDN) 





SGSN node name 


CO 


This IE shall be sent by the new SGSN on the S3 interface 


FQDN 
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if both new SGSN and associated SGW support ISR. See 
NOTE 2. 






MME node name 


CO 


This IE shall be sent by the new MME on the S3 interface if 
both new MME and associated SGW support ISR. See 
NOTE 2. 


FQDN 


1 


Private Extension 







Private Extension 


VS 


NOTE 1 : 
NOTE 2: 

NOTE 3: 


The relaying SGSN shall fonward the Context Request message to the interface of the old SGSN, 
where the interface type is matching what is indicated in the IE S3/S16/S10 Address and TEID for 
Control Plane. 

According to the 3GPP TS 23.401 [3], during an inter-RAT handover procedure for a UE with ISR 
activated, the source MME/SGSN should select the ISR associated CN node for this UE as the target 
CN node for the inter RAT HO when the ISR associated CN node can serve the target access. This 
parameter is exchanged when ISR is being activated and used in the source MME/SGSN for this 
decision upon subsequent inter-RAT handover. 

The Complete TAU request message IE is available except during UTRAN/GERAN to E- 
UTRAN/UTRAN (HSPA) SRVCC procedure as specified in 3GPP TS 23.216 [43]. In these 
procedures, the new MME shall set the Indication IE MSV (MS Validated) flag to 1 . 



7.3.6 Context Response 

A Context Response message shall be sent as a response to a previous Context Request message during TAU/RAU 
procedure and UTRAN/GERAN to E-UTRAN/UTRAN (HSPA) SRVCC procedure. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

- "IMSI not known" 

- "P-TMSI Signature mismatch" 
"User authentication failed" 

Table 7.3.6-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.6-1 : Information Elements in a Context Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


Cause 


M 




Cause 





IMSI 


C 


Tfie IMSI shall be included In the message except for the 
case: 

If the UE is emergency attached and the UE is 
UlCCIess. 

The IMSI shall be included In the message but not used as 
an Identifier 

if UE is emergency attached but IMSI is not 

authenticated. 


IMSI 





MME/SGSN UE MM 
Context 


C 


This IE shall be Included If the Cause IE has the value " 
Request Accepted ". 


MM Context 





MME/SGSN UE EPS 
PDN Connections 


c 


This IE shall be included If there is at least a PDN 
connection for this UE on the sending MME/SGSN. 
Several lEs with this type and instance values shall be 
Included as necessary to represent a list of PDN 
Connections. 


PDN Connection 





Sender F-TEID for 
Control Plane 


c 


This IE shall be Included If the Cause IE has the value 
"Request Accepted". 


F-TEID 





SGWS11/S4IP 
Address and TEID for 
Control Plane 


c 


This IE shall be included if a SGW is being used by the old 

MME/SGSN, except if: 

the source and target MME/S4-SGSN support the 
MME/S4-SGSN triggered SGW restoration 
procedure, and the source MME/S4-SGSN has not 
performed the SGW relocation procedure after the 
source SGW has failed as specified in 3GPP TS 
23.007 [17]. 

across the S1 6 interface if there is no active PDP 
context 


F-TEID 


1 


SGW node name 


c 


This IE Identifies the SGW that was used by the old 
MME/SGSN and it shall be Included by the source 
MME/S4-SGSN with the following exceptions: 

the source and target MME/S4-SGSN support the 
MME/S4-SGSN triggered SGW restoration 
procedure, and the source MME/S4-SGSN has not 
performed the SGW relocation procedure after the 
source SGW has failed as specified In 3GPP TS 
23.007 [17]. 

across the SI 6 interface if there is no active PDP 
context 


FQDN 





Indication Flags 


c 


This IE shall be included if any of the flags are set to 1 . 

Idle mode Signalling Reduction Supported Indication: 
This flag shall be set to 1 If the Cause IE value 
Indicates "Request accepted" and the old system 
(including old MME/SGSN and the associated 
SGW) has the ISR capability. 

Unauthenticated IMSI: 

This flag shall be set to 1 If the IMSI present In the 
message is not authenticated and is for an 
emergency attached UE. 

Change Reporting support Indication flag: 

This flag shall be set to 1 if the Source S4- 
SGSN/MME supports Location Change Reporting 
mechanism. See NOTE 1 . See NOTE 2. 

CSG Change Reporting support Indication flag: 

This flag shall be set to 1 If the Source S4- 
SGSN/MME supports CSG Information Change 
Reporting mechanism. See NOTE 1 . See NOTE 2. 

ISRAU: 


Indication 
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This flag shall be set to 1 on SI 0/S1 6 interface if 
the ISR is activated for the UE before the UE 
moving to the new SGSN/MME. 










Management Based MDT allowed flag: 

This flag shall be set to 1 for the inter-MME TAU 
procedure over the S10 interface, if Management 
Based Minimization of Drive Tests (MDT) is 
allowed. See 3GPP TS 36.413 [10] and 3GPP TS 
32.422 [18]. 










SGW Restoration Needed Indication (SRNI): 

This flag shall be set to 1 if both source and target 
MME/S4-SGSN support the MME/S4-SGSN 
triggered SGW restoration procedure and the 
source MME/S4-SGSN has not performed the 
SGW relocation procedure after the source SGW 
has failed as specified in 3GPP TS 23.007 [17]. 






Trace Information 


C 


This IE shall be included when session trace is active for 
this IMSI/IMEI. 


Trace Information 





HRPD access node 
S101 IP address 


C 


This IE shall be included only if the HRPD pre registration 
was performed at the old MME 


IP-Address 





1xlWS S102 IP 
address 


C 


This IE shall be included only if the IxRTT CS fallback pre 
registration was performed at the old MME 


IP-Address 


1 


Subscribed RFSP 
Index 


CO 


This IE shall be included only during inter-MME/SGSN 
mobility procedures, if the source MME/SGSN receives it 
from an HSS. 


RFSP Index 





RFSP Index in Use 


CO 


This IE shall be included only during inter-MME/SGSN 
mobility procedures, if the source MME/SGSN supports the 
feature. 


RFSP Index 


1 


UE Time Zone 


CO 


When available, this IE shall be included by the source 
MME/S4-SGSN. 


UE Time Zone 





MME/S4-SGSN LDN 





This IE is optionally sent by the MME/S4-SGSN to the peer 
MME/S4-SGSN on the S3/S10/S16 interfaces (see 3GPP 
TS 32.423 [44]), when communicating the LDN to the peer 
node for the first time. 


Local 
Distinguished 
Name (LDN) 





MDT Configuration 


CO 


This IE shall be sent by the source MME to the target MME 
on the S1 interface for inter-MME TAU procedure, if the 
Job Type indicates Immediate MDT. See 3GPP TS 32.422 
[18] subclause 4.2.6. 


MDT 
Configuration 





SGSN node name 


CO 


This IE shall be sent by the old SGSN on the S3 interface if 
both old SGSN and associated SGW support ISR. See 
NOTE 3. 


FQDN 


1 


MME node name 


CO 


This IE shall be sent by the old MME on the S3 interface if 
both old MME and associated SGW support ISR. See 
NOTE 3. 


FQDN 


2 


Private Extension 







Private Extension 


vs 


NOTE 1: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1) 

defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In 
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change 
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change 
Reporting Support Indication. 

NOTE 2: The receiver shall ignore the per UE Change Reporting Support Indication and CSG Change 

Reporting Support Indication flags, as included within the Indication Flags IE above, if these flags are 
included per PDN connection i.e. within the Indication Flags IE of the MME/SGSN UE EPS PDN 
Connections IE. 

NOTE 3: According to the 3GPP TS 23.401 [3], during an inter-RAT handover procedure for a UE with ISR 

activated, the source MME/SGSN should select the ISR associated CN node for this UE as the target 
CN node for the inter RAT HO when the ISR associated CN node can serve the target access. This 
parameter is exchanged when ISR is being activated and used in the source MME/SGSN for this 
decision upon subsequent inter-RAT handover. 
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Table 7.3.6-2: MME/SGSN UE EPS PDN Connections within Context Response 



Octet 1 


PDN Connection ^^^B 109 (decimal) 


Octets 2 and 3 




:0etet4; 


^^^^^^^^pare andJnstanc^^^^^^^^^^^^^^^^^K 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


APN 


IVI 




APN 





APN Restriction 


C 


This IE denotes the restriction on the combination of types 
of APN for the APN associated with this EPS bearer 
Context. The target MME or SGSN determines the 
Maximum APN Restriction using the APN Restriction. 
If available, the source MME/S4 SGSN shall include this 
IE. 


APN Restriction 





Selection IVIode 


CO 


When available, this IE shall be included by the source 
MME/S4-SGSN 


Selection Mode 





IPv4 Address 


c 


This IE shall not be included if no IPv4 Address is 
assigned. See NOTE 1 . 


IP Address 





IPv6 Address 


c 


This IE shall not be included if no IPv6 Address is 
assigned. 


IP Address 


1 


Linked EPS Bearer ID 


IVI 


This IE identifies the default bearer of the PDN 
Connection. 


EBI 





PGW S5/S8 IP 
Address for Control 
Plane or PMIP 


M 


This IE shall include the TEID in the GTP based S5/S8 
case and the GRE key in the PMIP based S5/S8 case. 


F-TEID 





PGW node name 


c 


This IE shall be included if the source MME or SGSN has 
the PGW FQDN. 


FQDN 





Bearer Contexts 


M 


Several lEs with this type and instance values may be 
included as necessary to represent a list of Bearers. 


Bearer Context 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 




AMBR 





Charging 
characteristics 


C 


This IE shall be present if charging characteristics was 
supplied by the HSS to the MME/SGSN as a part of 
subscription information. 


Charging 
characteristics 





Change Reporting 
Action 


c 


This IE shall be included whenever available at the source 
MME/SGSN. 


Change Reporting 
Action 





CSG Information 
Reporting Action 


CO 


This IE shall be included whenever available at the source 
MME/SGSN. 


CSG Information 
Reporting Action 





H(e)NB Information 
Reporting 


CO 


This IE shall be included whenever available at the source 
MME/SGSN. 


H(e)NB 
Information 
Reporting 





Indication flags 


CO 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Subscribed QoS Change Indication: This flag shall 
be set to 1 if the subscribed QoS profile of the 
related PDN connection has changed in the old 
MME/SGSN when the UE is in ECM-IDLE state 
and ISR is activated. 

Change Reporting support indication flag: This flag 
shall be set to 1 if the Source S4-SGSN/MME 
supports Location Change Reporting mechanism 
and if the S4-SGSN/MME has indicated the 
support for the Location Change Reporting 
mechanism to the PGW, during the session 
establishment and/or modification procedures. See 
NOTE 2. 

CSG Change Reporting Support Indication flag: 
This flag shall be set to 1 if the Source S4- 
SGSN/MME supports CSG Information Change 
Reporting mechanism and if the S4-SGSN/MME 
has indicated the support for the CSG Information 
Change Reporting to the PGW, during the session 
establishment and/or modification procedures. See 
NOTE 2. 


Indication 
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Signalling Priority 
Indication 


CO 


The source SGSN/MME shall include this IE if the UE 
indicated low access priority when establishing the PDN 
connection. 


Signalling Priority 
Indication 





Change to Report 
Flags 


CO 


This IE shall be included by the MME/SGSN if any one of 

the applicable flags is set to 1 . 

Applicable flags: 

Serving Network Change to Report: This flag shall 
be set to 1 if the source MME/SGSN has detected 
a Serving Network change during a TAU/RAU 
procedure without MME/SGSN change but has not 
yet reported this change to the PGW. 

Time Zone Change to Report: This flag shall be set 
to 1 if the source MME/SGSN has detected a UE 
Time Zone change during a TAU/RAU procedure 
without MME/SGSN change but has not yet 
reported this change to the PGW. 


Change To 
Report Flags 





NOTE 1 : For deferred IPv4 address allocation, if the MME/S4-SGSN receives the PDN address "0.0.0.0" from 
PGW during "eUTRAN Initial Attach", "PDF Context Activation", "UE requested PDN Connectivity", 
then the IV1IVIE/S4-SGSN shall include this IPv4 address "0.0.0.0". 

NOTE 2: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1) 

defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In 
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change 
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change 
Reporting Support Indication. 



The Bearer Context shall be coded as depicted in Table 7.3.6-3. 



Table 7.3.6-3: Bearer Context within iUliUIE/SGSN UE EPS PDN Connections witliin Context Response 



Octet 1 


Bearer Context IE Type = 93 


Octets 2 and 3 


Length = n 








Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 


C 


This IE shall be present if a TFT is defined for this bearer. 


Bearer TFT 





SGW S1/S4/S12 IP 
Address and TEID for 
user plane 


C 


The IE shall be present except if: 

the source and target MME/S4-SGSN support the 
MME/S4-SGSN triggered SGW restoration 
procedure, and the source MME/S4-SGSN has not 
performed the SGW relocation procedure after the 
SGW has failed as specified in 3GPP TS 23.007 
[17]. 


F-TEID 





PGW S5/S8 IP 
Address and TEID for 
user plane 


C 


This IE shall only be included for GTP based S5/S8. 


F-TEID 


1 


Bearer Level QoS 


M 




Bearer Level QoS 





BSS Container 


CO 


The MME/S4 SGSN shall include the Packet Flow ID, 
Radio Priority, SAPI, PS Handover XID parameters in the 
TAU/RAU/Handover procedure, if available. 


F-Container 





Transaction Identifier 


C 


This IE shall be sent over S3/S10/S16 if the UE supports 
A/Gb and/or lu mode. 


Tl 






7.3.7 Context Acknowledge 

A Context Acknowledge message shall be sent as a response to a previous Context Response message, only if the 
previous Context Response message is received with the acceptance cause. 

Possible cause values are speciiied in Table 8.4-1. Message speciiic cause values are: 

- "User authentication failed" . 
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Table 7.3.7-1 specifies the presence requirements and conditions of the lEs in the message. 



Table 7.3.7-1 : Information Elements in a Context Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Indication flags 


C 


This IE shall be included if any one of the applicable flags 
is set to 1 . 

Applicable Flags are: 
SGWCI: 

SOW change indication indicates a new SGW has 

been selected. The old MME/old SGSN marks in 

itQ rTintPYt that thp infnrmation in thp fn\A/Q anri thp 

1 Lo OUI 1 LCAL LIICtL LIIC IIIIUIIIICtLlVJII III LIIC '•J Wo dl ILi 11 IC? 

HSS are invalid 

ISRAI: 

This flag indicates to the old system that it shall 
maintain the UE's contexts. This flag shall be set to 
1 if the Cause IE value indicates "Request 
accepted" and ISR is activated as specified in 
3GPP TS 23.401 [3]. 

See N0TE1 . 


Indication 





Private Extension 







Private Extension 


VS 


N0TE1 : For the Indication Flags, the combination (SGWCI, ISRAI) = 1,1 shall be considered an error if 
received. 



7.3.8 Identification Request 

If the UE identifies itself with temporary identity and it has changed SGSN/MME since detach in Attach procedure, the 
new MME/SGSN shall send an Identification Request message to the old SGSN/MME over S3, S16 or SIO interface to 
request IMSI. 

Table 7.3.8-1 specifies the presence requirements and conditions of the lEs in the message. 

If the sending/new node is a MME, it shall include in the Identification Request message: 

- the GUTI IE and Complete Attach Request Message IE, if the GUTI or the indication of mapped or native GUTI 
received from UE indicates the old node is a MME, as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. 

the RAl P-TMSI, which was derived from the GUTI received from UE, and the P-TMSI Signature that was 
received intact from the UE, if the GUTI or the indication of mapped or native GUTI indicates the old node is an 
SGSN as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. 

If the sending/new node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Identification 
Request message. If the receiving/old node is an MME, it shall construct GUTI according to the RAI IE, P-TMSl IE 
and P-TMSI Signature IE (see the mapping relationship between RAI, P-TMSI, P-TMSI signature and GUTI defined in 
3GPP TS23.003[2]), and find UE context via this GUTI. 

The new MME differentiates the type of the old node as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. If the 
old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; if the old node is a MME, the 
new MME include GUTI IE and Complete Attach Request Message IE in the Identification Request message. The 
Mapping between temporary and area identities is defined in 3GPP TS 23.003 [2]. 

The GUTI IE shall not coexist with any of the RAI IE, P-TMSI IE and P-TMSI Signature IE in an Identification 
Request message. If this occurs, the receiving node shall return a corresponding cause value in the response message. 

The Target PLMN ID IE shall be used in old SGSN/MME in order to decide whether un-used authentication vectors to 
be distributed to new SGSN/MME or not. Distribution and use of authentication vectors between different serving 
network domains are specified in 3 GPP TS 33.401 [12]. 
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Table 7.3.8-1 : Information Elements in an Identification Request 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










GUTI 


C 


The new W\W\E shall include this IE over S10 interface. 


GUTI 





Routeing Area 


c 


'1^1 III—' 1— II t~\r\ it~\ .A f\ ' J. _£ '£ i.t 1 iTi 

This IE shall be included over S3/S16 interface, if the GUTI 


III 1 £ f\ A 1 

ULI for RAI 





Identity(RAI) 




or the indication of mapped or native GUTI received from 
the UE inaicates the old node is an SQSN, the new MME 
maps this It from uU 1 1. 






Packet TMSI(P-TMSI) 


c 


This IE shall be included over S3/S1 6 interface. For the S3 
interface, if sent by the MME, this IE is derived by the MME 
from the GUTI received from the UE. 


P-TMSI 





P-TMSI Signature 


c 


-I- 1" 1^ 1 III 1 1 1 _ _ \ ^ r\ ' J J '£ '1. ■ — 

This IE shall be included over S3/S16 interface, if it is 
received from the UE. 


P-TMSI Signature 





Complete Attach 
Request Message 


c 


The new MME shall include this IE over S10 interface, and 
the old MME may use this IE for integrity checl<. 


Complete 
Request Message 





Address for Control 





If an SGSN within the same SGSN pool with the old SGSN 


IP Address 





Plane 




receives this message, the SGSN shall include the old IP 
address of the received message in this optional 
parameter if this IE is not present and relay the message to 
the old SGSN. 






UDP Source Port 


c 


If an SGSN within the same SGSN pool as the old SGSN 


Port Number 





Number 




receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
parameter if this IE is not present and relay the message to 
the old SGSN. The old SGSN shall use this UDP port as 
the UDP destination port of the Identification Response 
message. 






Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise, the SGSN may include a Hop Counter with a 
value of max-1 , and may relay the message to the old 
SGSN. 


Hop Counter 





Target PLMN ID 


CO 


If available, this IE shall be included in order to allow old 
MME/SGSN to make a judgment whether un-used 
authentication vectors to be distributed or not. 


Serving Network 





Private Extension 





None 


Private Extension 


VS 



7.3.9 Identification Response 

The old SGSN/MME shall send an Identification Response message to the new MME/SGSN as a response to a previous 
Identification Request message over S3/S10/S16 interface. 

Table 7.3.9-1 specifies the presence requirements and conditions of the IBs in the message. 

For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, if an old SGSN within an SGSN pool receives an 
Identification Request message that contains the optional parameter Address for Control Plane, the old SGSN shall use 
this address as destination IP address of the Identification Response message. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

"P-TMSI Signature mismatch" 

"User authentication failed" 

Only the Cause information element shall be included in the response if the Cause contains another value than "Request 
accepted". 



ETSI 



3GPP TS 29.274 version 1 1 .5.0 Release 11 118 ETSI TS 1 29 274 V1 1 .5.0 (201 3-01 ) 



Table 7.3.9-1 : Information Elements in an Identification Response 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


cici iici lis 










Cause 


M 




Cause 





IMSI 


C 


This IE shall be included if the Cause contains the value 
"Request accepted". 


IMSI 





MME/SGSN UE MM 


C 


This IE shall be included if Attach Request is integrity 


MM Context 





Context 




protected 






Trace Information 


CO 


This IE shall be included when session trace is active for 
this IMSI/IMEI. 


Trace Information 





Private Extension 







Private Extension 


vs 



7.3.10 Forward Access Context Notification 

A Forward Access Context Notification message shall be sent from the Old SGSN to the New SGSN over the S16 
interface to forward the RNC contexts to the target system, or sent from the Old MME to the New MME over the SIO 
interface to forward the RNC/eNodeB contexts to the target system. 

When the old SGSN receives the RANAP message Forward SRNS Context, the old SGSN shall send a Forward Access 
Context Notification message to the new SGSN. The new SGSN shall forward the message to the target RNC using the 

corresponding RANAP message. 

When the old SGSN receives a BSSGP message PS handover Required and the acknowledged peer-to-peer LLC 
operation is used for the Bearer Context or when "delivery order" is set in the Bearer Context QoS profile, the old 
SGSN shall send a Forward Access Context Notification message with the PDU Number IE to the new SGSN. The new 
SGSN shall forward the message to the target RNC/ target BSS using the corresponding RANAP message only for PS 
handover to lu mode. 

When the old SGSN receives a BSSGP message PS handover Required from source BSS/RNC for PS handover to 
A/Gb mode, the value part of RAB Context IE shall be empty according to its defined minimum length. 

Table 7.3.10-1 specifics the presence requirements and conditions of the lEs in the message. 



Table 7.3.10-1 : Information Elements in a Forward Access Context Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


RAB Contexts 


C 


This IE shall be included for S16 only. Several lEs with this 
type and instance values shall be included as necessary to 

represent a list of Bearers. 

For each RAB context in the received RANAP message, 
the old SGSN shall include this IE in the message. 


RAB Context 





Source RNC PDCP 
context Info 


C 


If available, the old SGSN shall include an Source RNC 
PDCP context info in the message. 


Source RNC 
PDCP context 
Info 





PDU Numbers 


c 


This IE only applies to S16. The old SGSN shall include 
this IE in the message if the acknowledged peer-to-peer 
LLC operation is used for the Bearer Context or when 
"delivery order" is set in the Bearer Context QoS profile in 
A/Gb mode to lu//VGb mode PS handover. 


PDU Numbers 





E-UTRAN 

Transparent 

Container 


c 


This IE shall be included over S10 to contain the "eNB 
Status Transfer Transparent Container" as specified 
inSGPPTS 36.413 [10]. 
Container Type shall be set to 3. 


F-Container 





Private Extension 







Private Extension 


vs 



7.3.1 1 Forward Access Context Acknowledge 

A Forward Access Context Acknowledge message shall be sent to the old MME/SGSN as a response to Forward 
Access Context Notification. 

Possible Cause values are specified in Table 8.4-1. 
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Table 7.3.11-1 specifics the presence requirements and conditions of the lEs in the message. 



Table 7.3.11-1: Information Elements in a Forward Access Context Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


vs 



7.3.12 Detach Notification 

A Detach Notification message shall be sent from an MME to the associated SGSN, or from an SGSN to the associated 
MME as a part of Detach procedure if the ISR is activated between the MME and SGSN for the UE. 

Possible Cause values are: 

"Local Detach". 

"Complete Detach". 

A Detach Notification message shall also be sent from an SGSN to the associated MME as a part of Detach procedure if 
the ISR is activated between the MME and SGSN for the UE. 

Possible Cause values are: 

- "IMSI Detach only". 

"Local Detach" indicates that this detach is local to the MME/SGSN and so the associated SGSN/MME registration 
where the ISR is activated shall not be detached. The MME/SGSN that receives this message including this Cause value 
of "Local Detach" only deactivates the ISR. This Cause value shall be included in the procedures: 

MME/SGSN-initiated Detach Procedure in case of implicit detach. 

"Complete Detach" indicates both the MME registration and the SGSN registration that the ISR is activated for, shall be 
detached. This "Complete Detach" Cause value shall be included in the procedures: 

UE-initiated Detach Procedure. 

MME/SGSN-initiated Detach Procedure in case of explicit detach. 

For the purpose of SGs handling, the SGSN shall include Detach Type in the Detach Notification message for 
"Complete Detach" when the UE is combined IMSI/EPS attached and the ISR is activated. 

Possible Detach Type values are: 

- "PS Detach". 

"Combined PS/CS Detach". 

"PS Detach" indicates that the MME shall perform exphcit IMSI detach from EPS service as specified in section 5.4, 
3GPP TS 29.1 18 [22]. "Combined PS/CS detach" indicates that the MME shall perform explicit IMSI detach from non- 
EPS service as specified in section 5.5, 3GPP TS 29.118 [22]. 

"IMSI Detach only" indicates that combined IMSI/EPS attached UE initiates IMSI only GPRS detach from non-GPRS 
service as specified in section 4.7.4.1, 3GPP TS 24.008 [5], and both the SGSN/MME registration shall be remained. 
The MME shall perform exphcit IMSI detach from non-EPS service for the SGs handling purpose, which is specified in 
section 5.5, 3GPP TS 29.118 [22]. This "IMSI Detach only" Cause value shall be included in the procedures: 

- UE-initiated Detach Procedure for GERAN/UTRAN for "IMSI Detach only" . 
Table 7.3.12-1 specifics the presence of the lEs in the message. 
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Table 7.3.12-1: Information Elements in a Detach Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


IVI 




Cause 





Detach Type 


CO 


This IE shall be included by SGSN when the Cause 
indicates "Complete Detach" for the combined IMSI/EPS 
attached UE. 


Detach Type 





Private Extension 







Private Extension 


VS 



7.3.13 Detach Acknowledge 

A Detach Acknowledge message shall be sent as a response to a Detach Notification message during Detach procedure. 

Possible Cause values are specified in Table 8.4-1. 

Table 7.3.13-1 specifics the presence of the lEs in the message. 



Table 7.3.13-1: Information Elements in a Detach Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 







Recovery 





Private Extension 







Private Extension 


VS 



7.3.14 Change Notification Request 

3GPP TS 23.401 [3] and 3GPP TS 23.060 [4] specify that if PGW has requested ECGI/TAI/CGI/SAI/RAI Change 
Reporting and if MME/S4-SGSN supports the feature, then MME/S4-SGSN shall send the Change Notification Request 

message on the S11/S4 interface to the SGW. If SGW supports the feature, the SGW forwards the message on the GTP 
based S5/S8 interface to the PGW as part of location dependent charging related procedures. 

In this version of the specification, the sender shall set the header TEID value to that of the peer node"s Control Plane 
TEID on S11/S4 interface or to the peer node"s Control Plane TEID on S5/S8 interface. However a receiver shall be 
prepared to receive messages in which the header TEID value is set to zero from implementation conforming to earlier 
versions of this specification. When that is the case, the receiver identifies the subscriber context based on the included 
LBI, IMSI, and/or MEI lEs. 
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Table 7.3.14-1: Information Element in Change Notification Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


C 


The MME/SGSN shall include IMSI in the message except 
for the case: 

- If the UE is emergency attached and the UE is 
UIGGIess. 

The IMSI shall be included in the message but not used as 

an identifier 

- if UE is emergency attached but IMSI is not 

authenticated. 

If the SGW receives this IE, it shall fonward it to the PGW 
on S5/S8. 


IMSI 





ME Identity (I^EI) 


C 


The MME/SGSN shall include the ME Identity (MEI) IE: 

- If the UE is emergency attached and the UE is 
UIGGIess 

- If the UE is emergency attached and the IMSI is not 
authenticated 

If the SGW receives this IE, it shall fonward it to the PGW 
on S5/S8. 


MEI 





Indication Flags 


CO 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags are: 

Unauthenticated IMSI: This flag shall be set to 1 if 
the IMSI present in the message is not 
authenticated and is for an emergency attached 
UE. 


Indication 





RAT Type 


M 




RAT Type 





User Location 
Information (ULI) 


C 


The SGSN shall include the User Location Information IE if 
the MS is located in a RAT Type of GERAN, UTRAN or 
GAN and shall include the GGI, SAI and/or RAI. 


ULI 







CO 


The MME shall include the User Location Information IE if 
the UE is located in a RAT Type of E-UTRAN and shall 
include the ECGI and/or TAI. 








CO 


If the SGW receives this IE it shall forward it to the PGW, if 
it supports this feature. 






User CSG 
Information (UCI) 


CO 


The SGSN/MME shall include the User CSG Information 
IE if the MS is located in the CSG cell or the hybrid cell and 
the P-GW/PCRF decides to receive the CSG Information. 
It the b(jW receives this it it shall forward it to the rbW, it 
it supports this feature. 


UGI 





PGW S5/S8 GTP-C 


C 


This IE shall be sent on S4. 


IP Address 





IP Address 


CO 


This IE shall be sent on S1 1 . 






LBI 


CO 


This IE, identifying the PDN connection, shall be sent by 
the MME/SGSN on S11/S4. 

If the SGW receives this IE, it shall fonward it to the PGW 
on S5/S8. 


EBI 





Private Extension 





Vendor or operator specific information 


Private Extension 


vs 



7.3.15 Change Notification Response 

The Change Notification Response message may be sent on the SI 1/S4 interface by the SGW to the MME/SGSN and is 
sent on the S5/S8 interface by the PGW to the SGW as part of location dependent charging related procedures to 
acknowledge the receipt of a Change Notification Request. 

If SGW does not support the feature (see subclause 7.3.14 "Change Notification Request"), SGW may silently discard 

Change Notification Request message from MME/SGSN. If the MME/ SGSN does not receive Change Notification 
Response, the MME/SGSN may either send Change Notification Request to the same SGW next time UE location 
changes, or not (marking SGW as not supporting the feature). 
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The Cause value indicates whether or not the Change Notification Request was received correctly. Possible Cause 
values are specified in Table 8.4-1. Message specific cause values are: 

"Request accepted". 

"Request accepted partially" . 

- "IMSI/IMEI not known" . 

In this version of the specification, the sender shall set the header TEID value to that of the peer node"s Control Plane 
TEID on S11/S4 interface or to the peer node"s Control Plane TEID on S5/S8 interface. However a receiver shall be 
prepared to receive messages in which the header TEID value is set to zero from implementation conforming to earlier 
versions of this specification. When that is the case, the receiver identifies the subscriber context based on the included 
LBI, IMSI, and/or MEI lEs. 

If the IMSI is unknown, or the IMEI is unknown when the UE is emergency attached and UlCCless or the UE is 
emergency attached but the IMSI is not authenticated for the receiving GTP-C entity, then the message shall be silently 
discarded and no further processing of the lEs shall continue. 

If the MME/SGSN receives Change Notification Response containing a Cause value of "IMSWMEI not known" and 
CS bit set to 1, this indicates that the associated PDN connection does not exist within the PGW. The Change Reporting 
mechanism shall be stopped in the receiving SGSN/MME for all Bearers of the associated PDN connection. The 
SGSN/MME shall then initiate PDN discormection for all of these PDN Cormections. 

If the PDN Connection associated of the Change Notification Request message received by the SGW does not exist 
within the SGW, the SGW shall return Change Notification Response with the CS bit set to to the MME/SGSN. The 
Change Reporting mechanism shall be stopped in the receiving SGSN/MME for all Bearers of the associated PDN 
cormection, and the MME/SGSN shall then locally delete the PDN cormection and release all associated resources. 

If the location Change Reporting mechanism is to be stopped or modified for this subscriber in the SGSN/MME, then 
the PGW shall include the Change Reporting Action IE in the message and shall set the value of the Action field 
appropriately. 



Table 7.3.15-1: Information Element in Change Notification Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


ins. 


IMSI 


C 


The IMSI shall be included in the message if it is received 
in the Change Notification Request message. 


IMSI 





ME Identity (MEI) 


C 


The ME Identity (MEI) shall be included in the message if it 
is received in the Change Notification Request message. 


MEI 





Cause 


M 




Cause 





Change Reporting 
Action 


C 


This IE shall be included with the appropriate Action field If 
the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





CSG Information 
Reporting Action 


CO 


This IE shall be included with the appropriate Action field if 
the location CSG Info reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


CSG Information 
Reporting Action 





Private Extension 







Private Extension 


vs 



7.3.16 Relocation Cancel Request 

A Relocation Cancel Request message shall be sent from the source MME/SGSN to the target MME/SGSN on 
S3/S10/S16 interface as part of the Inter RAT handover Cancel procedure/Sl Based handover Cancel procedure and on 
the S16 interface as part of the SRNS Relocation Cancel Procedure.Table 7.3.16-1 specifics the presence of the lEs in 
the message. 
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Table 7.3.16-1: Information Elements in Relocation Cancel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


C 


The IMSI shall be included in the message except for the 
case: 

- If the UE is emergency attached and the UE is 
UlCCIess. 

The IMSI shall be included in the message but not used as 
an identifier 

if UE is emergency attached but IMSI is not 

authenticated. 


IMSI 





ME Identity (I^EI) 


C 


The MME/SGSN shall include the ME Identity (MEI) IE: 

- If the UE is emergency attached and the UE is 

UlCCIess 

- If the UE is emergency attached and the IMSI is not 
authenticated 


MEI 





Indication Flags 


CO 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags are: 

Unauthenticated IMSI: This flag shall be set to 1 if 
the IMSI present in the message is not 
authenticated and is for an emergency attached 
UE. 


Indication 





RANAP Cause 


c 


This IE shall be present in the case of SRNS relocation 
cancel procedure. It shall contain the cause value received 
from the source RNC in the Relocation Cancel message 
received over the lu interface. 


F-Cause 





Private Extension 







Private Extension 


vs 



7.3.17 Relocation Cancel Response 

A Relocation Cancel Response message shall be sent as a response to a previous Relocation Cancel Request message 
during the Inter RAT handover Cancel procedure/Sl Based handover Cancel procedure/SRNS Relocation Cancel 
Procedure. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 

- "IMSI/IMEI not known" . 
Table 7.3.17-1 specifics the presence of the lEs in the message. 



Table 7.3.17-1: Information Elements in Relocation Cancel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 



7.3.18 Configuration Transfer Tunnel 

A Configuration Transfer Tunnel message shall be used to tunnel cNodeB Configuration Transfer messages from a 
source MME to a target MME over the SIO interface. The purpose of the eNodeB Direct Configuration Transfer is to 
transfer information from an eNodeB to another eNodeB in unacknowledged mode (see 3GPP TS 36.413 [10]). 

Table 7.3.18-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.18-1 : Information Elements in a Configuration Transfer Tunnel lUlessage 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


E-UTRAN 

Transparent 

Container 


M 


This IE shall contain the "SON Configuration Transfer" as 
specified in 3GPP TS 36.413 [10]. 
Container Type shall be set to 3. 


F-Container 





Target eNodeB ID 


M 


This IE shall contain the ID of the target eNodeB 


Target 
Identification 






7.3.19 RAN Information Relay 

The RAN Information Relay message shall be sent on S3 interface between SGSN and MME to transfer the RAN 
information received by an SGSN from BSS or RNS (or GERAN lu mode) or by an MME from eNodeB. The 
procedures are specified in 3GPP TS 23.401 [3]. 

This message shall also be sent on S16 interface to transfer the RAN information between GERAN or GERAN lu mode 
orUTRAN. 

For handling of protocol errors the RAN Information Relay message is treated as a Response message. 
Table 7.3.19-1 specifies the presence requirements and conditions of the lEs in the message. 



Table 7.3.19-1: Information Elements in a RAN Information Relay 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


BSS Container 


IVI 


All information elements from the BSSGP RIM PDU, 
starting from and including the BSSGP "PDU type", shall 
be contained within the BSS Container and forwarded to 
the destination MME/SGSN in the RAN Information Relay 
message. The Container Type shall be set to 2. 


F-Container 





RIM Routing Address 


c 


This IE shall be included if the RIM Routing Address 
information is included in the message sent from the 
source RAN node. 

This IE identifies the destination RAN node where the RAN 
Information needs to be relayed to. It contains: 

the destination RNC Identity when the target is 

GERAN lu mode or UTRAN; or 

the destination Cell Identity when the target is 
GERAN; or 

the Target eNodeB ID when the target is E- 
UTRAN. 


Target 
Identification 





Private Extension 





None 


Private Extension 


vs 



7.3.20 ISR Status Indication 

A ISR Status Indication message shall be sent on the S3 interface by the MME/SGSN to the ISR associated 
SGSN/MME as part of the Restoration of PDN connections after an SGW failure for UEs with ISR as specified in 
3GPP TS 23.007 [17]. 

Table 7.3.20-1 specifies the presence of the lEs in the message. 
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Table 7.3.20-1 : Information Elements in an ISR Status Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Action Indication 


IVI 


This IE shall include one of the applicable Values: 

Deactivation Indication: If the value is set to 1 to 
indicate the ISR associated MME/SGSN to 
deactivate ISR and remove the UE resource 
locally. 

Paging Indication: If the value is set to 2 to indicate 
the ISR associated MME/SGSN to page the UE in 
IDLE state. 


Action Indication 





Private Extension 







Private Extension 


VS 



7.4 CS Fallback and SRVCC related messages 
7.4.1 Suspend Notification 

The Suspend Notification message shall be sent on the SI 1 interface by the MME to the SGW and on the S5/S8 
interface by the SGW to the PGW as part of the IxRTT CS fallback procedures in 3GPP TS 23.272 [21]. 

The Suspend Notification message shall be sent on the S3 interface by the SGSN to the MME, on the SI 1 interface by 
the MME to the SGW, and on the S5/S8 interface by the SGW to the PGW as part of the SRVCC procedures in 3GPP 
TS 23.216 [43] or the CS fallback from E-UTRAN access to UTRAN/GERAN CS domain access related procedures in 
3GPPTS 23.272 [21]. 

The Suspend Notification message shall be sent on the S16 interface as per the inter-SGSN suspend procedures in 3GPP 
TS 23.060 [35]. 

The Suspend Notification message shall be sent on the SI 6, the S4 and the S5/S8 interfaces as part of the SRVCC from 
UTRAN (HSPA) to GERAN without DTM support procedure in 3GPP TS 23.216 [43]. 

The Suspend Notification message shall be sent on the S4 and the S5/S8 interfaces as part of the CS fallback from E- 
UTRAN to GERAN CS domain related procedures in 3GPP TS 23.272 [21]. 

After receiving a Suspend Notification message, the SGW/PGW marks all the non-GBR bearers as suspended status. 
The PGW should discard packets it receives for the suspended UE. 

Table 7.4.1-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.4.1-1: Information Element in Suspend Notification 



Informstion 


n 

r 


Condition / Cominent 


IE Type 


Ins. 


elements 










iiv yio 1 
IMbl 




This IE shall be included only on the S1 1 interface. 


1 ^ yio 1 


(J 


Routeing Area 
Identity(RAI) 




This IE shall be included only on the S3 interface. 
See NOTE 1 . 


1 II 1 tnf D A 1 

ULI Tor rlAI 


U 




CO 


This IE shall be included on the S16 interface. 






Linked Bearer Identity 


CO 


This IE shall be included on the S1 1/S4 interface to 


EBI 





(LBI) 




indicate the default bearer associated with the PDN 
connection. 






Packet TMSI(P-TMSI) 


c 


This IE shall be included only on the S3 interface. 
See NOTE 1 . 


P-TMSI 







CO 


This IE shall be included on the S16 interface. 






Originating Node 


CO 


This IE shall be sent on S1 1 interface, if before MME 
initiates a Detach procedure (a) ISR was active in the MME 
and (b) the MME was in EMM-Connected state (see also 
8.65). 

This IE shall be sent on S4 interface, if before S4-SGSN 

initiates a Detach procedure (a) ISR was active in the 
SGSN and (b) the SGSN was in PMM-Connected state 
(see also 8.65). 


Node Type 





Address for Control 


CO 


If an SGSN within the same SGSN pool with the old SGSN 


IP Address 





Plane 




receives this message, the SGSN shall include the source 
IP address of the received message in this optional 
parameter if this IE is not present and relay the message to 
the old SGSN. 






UDP Source Port 


CO 


If an SGSN within the same SGSN pool as the old SGSN 


Port Number 





Number 




receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
parameter if this IE is not present and relay the message to 
the old SGSN. The old SGSN shall use this UDP port as 
the UDP destination port of the Suspend Acknowledge 
message. 






Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise, the SGSN may include a Hop Counter with a 
value of max-1 , and may relay the message to the old 
SGSN. 


Hop Counter 





Private Extension 







Private Extension 


vs 


NOTE 1 : If the ISR is not active, tine MME can not suspend the bearers after receving the Suspend Notification 
message from the SGSN, the GUTI can not be derived from the P-TMSI and RAI pair as the P-TMSI 
Signature is not included in the message. The MME shall still reply the Suspend Acknowledge to the 
SGSN. Suspend procedure on MME, SGW and PGW are triggered by the S1 UE Context Release 
message sent from the eNodeB to the MME. Refer to section 6.3 and section 7.4 in 3GPP TS 23.272 
[21] for detail. 



7.4.2 Suspend Acknowledge 

The Suspend Acknowledge message shall be sent on the S 1 1 interface by the SGW to the MME and on the S5/S8 
interface by the PGW to the SGW as part of the IxRTT CS fallback procedures in 3GPP TS 23.272 [21]. 

The Suspend Acknowledge message shall be sent on the S3 interface by the MME to the SGSN, on the SI 1 interface by 
the SGW to the MME and on the S5/S8 interface by the PGW to SGW as part of the SRVCC procedures in 3GPP TS 
23.216 [43] or the CS fallback from E-UTRAN access to UTRAN/GERAN CS domain access related procedures in 
3GPPTS 23.272 [21]. 

The Suspend Acknowledge message shall be sent on the S16 interface as per the inter-SGSN suspend procedures in 
3GPP TS 23.060 [35]. 

The Suspend Acknowledge message shall be sent on the SI 6, the S4 and the S5/S8 interfaces as part of the SRVCC 
from UTRAN (HSPA) to GERAN without DTM support procedure in 3GPP TS 23.216 [43]. 
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The Suspend Acknowledge message shall be sent on the S4 and the S5/S8 interfaces as part of the CS fallback from E- 
UTRAN to GERAN CS domain related procedures in 3GPP TS 23.272 [21]. 

Possible Cause values are specified in Table 8.4-1. 

For backward compatibility, if the IMSI IE is missing in the Suspend Notification message that is received on the S 11 
interface, the cause value "Mandatory IE missing" shall be used. 

Table 7.4.2-1 specifies the presence requirements and conditions of the lEs in the message. 



Table 7.4.2-1 : Information Element in Suspend Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


vs 



7.4.3 Resume Notification 

The Resume Notification message should be sent on the SI 1 interface by the MME to the SOW and forwarded on the 
S5/S8 interface by the SOW to the PGW as part of the resume procedure returning back to E-UTRAN in the case of CS 
fallback or SRVCC. 

The Resume Notification message should also be sent on the S4 interface by the SGSN to the SGW and forwarded on 
the S5/S8 interface by the SGW to the PGW as part of the resume procedure returning from SRVCC to HSPA if there is 
no Modify Bearer Request message sent to the SGW and PGW as specified in 3GPP TS 23.216 [43]. 

The SGW may also send a Resume Notification message to the PGW on the S5/S8 interface upon receipt from the 
MME/S4-SGSN of a (non-empty) Modify Bearer Request used as an implicit resume of the suspended bearers in the 
SGW and in the PGW (see 3GPP TS 23.216 [43] sections 6.2.2.1 and 6.3.2.1, 3GPP TS 23.272 [21] sections 6.3, 6.5 
and 7.4) if the conditions of presence of the lEs in the Modify Bearer Request specified in table 7.2.7-1 do not require 
any IE to be sent over S5/S8 to the PGW. 

NOTE: This is an alternative to sending over S5/S8 a Modify Bearer Request used as an implicit resume with 

zero IE(s), see subclause 7.2.7. 

After receiving a Resume Notification message or a Modify Bearer Request used as an implicit resume of the 
suspended bearers, the SGW/PGW clears suspended status for all the non-GBR bearers. The PGW shall forward 
packets it receives for the UE. 

Table 7.4.3-1 specifies the presence requirements and conditions of the lEs in the message. 



Table 7.4.3-1 : Information Element in Resume Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IIVISI 


IVI 




IMSI 





Unl<ed Bearer Identity 
(LBI) 


CO 


This IE shall be included on the S1 1/S4 interface to 
indicate the default bearer associated with the PDN 
connection. 


EBI 





Originating Node 


CO 


This IE shall be sent on S1 1 interface, if before MME 
initiates a Detach procedure (a) ISR was active in the MME 
and (b) the MME was in EMM-Connected state (see also 
8.65). 

This IE shall be sent on S4 interface, if before S4-SGSN 
initiates a Detach procedure (a) ISR was active in the 
SGSN and (b) the SGSN was in PMM-Connected state 
(see also 8.65). 


Node Type 





Private Extension 







Private Extension 


vs 
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7.4.4 Resume Acknowledge 

The Resume Acknowledge message should be sent on the S 11 interface by the SGW to the MME and on the S5/S8 by 
the PGW to the SGW as part of the resume procedure returning back to E-UTRAN in the case of CS fallback or 
SRVCC. 

The Resume Acknowledge message should also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 
interface by the PGW to the SGW as part of the resume procedure returning from SRVCC to HSPA if there is no 
Modify Bearer Request message sent to the SGW and PGW as specified in 3GPP TS 23.216 [43]. 

The PGW shall also send a Resume Acknowledge message to the SGW on the S5/S8 interface as a response to a 
Resume Notification message sent by the SGW upon receipt from the MME/S4-SGSN of a (non-empty) Modify Bearer 
Request used as an implicit resume of the suspended bearers in the SGW and in the PGW (see 3GPP TS 23.216 [43J 
sections 6.2.2.1 and 6.3.2.1, 3GPP TS 23.272 [21] sections 6.3, 6.5 and 7.4) if the conditions of presence of the lEs in 
the Modify Bearer Request specified in table 7.2.7-1 do not require any IE to be sent to the PGW. 

Possible Cause values are specified in Table 8.4-1. 

Table 7.4.4-1 specifies the presence requirements and conditions of the lEs in the message. 



Table 7.4.4-1 : Information Element in Resume Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


IVI 




Cause 





Private Extension 







Private Extension 


vs 



7.4.5 CS Paging Indication 

The CS Paging Indication shall be sent on the S3 interface by the MME to the associated SGSN when ISR is activated 
as part of mobile terminated CS services. The MME gets the related information from SGsAP-P AGING-REQUEST 
message as specified in 3GPP TS29.118 [21].Table 7.4.5-1 specifies the presence requirements and the conditions of 
the lEs in the message. 



Table 7.4.5-1 : Information Element in OS Paging Indication 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 








IIVISI 


M 




IMSI 





VLR Name 


M 




FQDN 





IIVISI 







IMSI 





Location area 







ULI 





identifier 










Global CN-ld 







Global CN-ld 





Channel needed 







Channel needed 





eMLPP Priority 







eMLPP Priority 





Service Indicator 


CO 


This IE shall be sent if the service type for the paging is 
available. 


Service Indicator 





Private Extension 







Private Extension 


vs 



7.4.6 Alert MME Notification 

An Alert MME Notification message shall be sent on the S3 interface by the MME to the associated SGSN as part of an 
SGs Non-EPS alert procedure (see 3GPP TS 29.118 [22]) when ISR is activated, except under the conditions specified 
in 3GPP TS 23.272 [21], to request to receive a notification when any activity from the UE is detected. 

Table 7.4.6-1 specifies the presence requirements and the conditions of the lEs in the message. 
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Table 7.4.6-1 : Information Element in Alert lUIME Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 







Private Extension 


VS 



7.4.7 Alert MME Acknowledge 

An Alert MME Acknowledge message shall be sent as a response to an Alert MME Notification message. 

Possible Cause values are specified in Table 8.4-1. 

NOTE: An SGSN implemented according to an earlier version of the specification will silently discard the Alert 
MME Notification message. An MME which does not receive an Alert MME Acknowledge message may 
not send further Alert MME Notification message to this SGSN. 

Table 7.4.7-1 specifies the presence requirements and the conditions of the lEs in the message. 



Table 7.4.7-1: Information Elements in Alert MME Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 



7.4.8 UE Activity Notification 

A UE Activity Notification message shall be sent on the S3 interface by the SGSN to the associated MME as part of an 
SGs Non-EPS alert procedure (see 3GPP TS 29.1 18 [22]) when ISR is activated, except under the conditions specified 
in 3GPP TS 23.272 [21 J, to indicate that activity from a UE has been detected. Table 7.4.8-1 specifies the presence 
requirements and the conditions of the lEs in the message. 



Table 7.4.8-1 : Information Element in UE Activity Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 







Private Extension 


VS 



7.4.9 UE Activity Acknowledge 

A UE Activity Acknowledge message shall be sent as a response to a UE Activity Notification message. 
Possible Cause values are specified in Table 8.4-1. 

Table 7.4.9-1 specifics the presence requirements and the conditions of the lEs in the message. 



Table 7.4.Z-1: Information Elements in UE Activity Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 
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7.5 Non-3GPP access related messages 
7.5.1 Create Forwarding Tunnel Request 

A Create Forwarding Tunnel Request message shall be sent by a MME to a Serving GW as a part of the MME 
configures resources for indirect data forwarding during active handover procedure from E-UTRAN to CDMA 2000 
HRPD access. 

Table 7.5.1-1 specifies the presence requirements and the conditions of the lEs in the message. 



Table 7.5.1-1: Information Elements in a Create Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


S103 PDN Data 
Forwarding Info 


M 


The MME shall include the forwarding Infomation for all 
PDN connections of the UE requesting data forwarding 
towards the HSGW in the message as S1 03 PDN Data 
Forwarding Info information elements. For each of those 
PDN Connections, an IE with the same type and instance 
value shall be included. 

The Serving GW shall forward downlinl< data to the HSGW 
via the GRE tunnel identified by the HSGW Address and 
HSGW GRE Key included in this information element when 
it receives downlinl< data forwarded from the eNodeB 
belonging to the corresponding EPS bearers of the PDN 
connection. 


S103PDF 





Private Extension 







Private Extension 


vs 



7.5.2 Create Forwarding Tunnel Response 

A Create Forwarding Tunnel Response message shall be sent by a Serving GW to a MME as a response to a Create 
Forwarding Timnel Request message. 

Table 7.5.2-1 specifies the presence requirements and the conditions of the lEs in the message. 

The Cause value indicates if Data Forwarding Resources has been created in the Serving GW or not. Data Forwarding 
Resources have not been created in the Serving GW if the Cause differs from "Request accepted". Possible Cause 
values are specified in Table 8.4-1. 

Only the Cause IE shall be included in the response if the Cause IE contains another value than "Request accepted". 



Table 7.5.2-1 : Information Elements in a Create Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





S1-U Data 


C 


S1-U Data Forwarding Info shall be included in the 


S1UDF 





Forwarding Info 




message if the Cause contains the value "Request 
accepted". For each EPS bearer requesting data 
forwarding which is included in the S103 PDN Data 
Forwarding Info fields of corresponding Create Forwarding 
Tunnel Request message, the Serving GW shall assign a 
Serving GW S1-U Address and Serving GW S1-U TEID 
pair and included it in the response message as S1-U Data 
Fon/varding Info information element. For each of those 
EPS bearers, an IE with the same type and instance value 
shall be included. 

The eNodeB shall forward downlink data of the EPS bearer 
to the Serving GW via the GTP-U tunnel identified by the 
Serving GW S1-U Address and Serving GW S1-U TEID. 






Private Extension 







Private Extension 


VS 
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7.6 Reliable Delivery of Signalling IVIessages 

Retransmission requirements in the current subclause do not apply to the Initial messages that do not have Triggered 
messages. 

Reliable delivery in GTPv2 messages is accomplished by retransmission of these messages. A message shall be 
retransmitted if and only if a reply is expected for that message and the reply has not yet been received. There may be 
limits placed on the total number of retransmissions to avoid network overload. 

Initial messages and their Triggered messages, as well as Triggered messages and their Triggered Reply messages are 
matched based on the Sequence Number and the IP address and port rules in subclause 4.2 "Protocol stack". Therefore, 
an Initial message and its Triggered message, as well as a Triggered message and its Triggered Reply message shall 
have exactly the same Sequence Number value. A retransmitted GTPv2 message (an Initial or a Triggered) has the 
exact same GTPv2 message content, including the OTP header, UDP ports, source and destination IP addresses as the 
originally transmitted GTPv2 message. 

For each triplet of local IP address, local UDP port and remote peer's IP address a GTP entity maintains a sending queue 
with signalling messages to be sent to that peer. The message at the front of the queue shall be sent with a Sequence 
Number, and if the message has an expected reply, it shall be held in a list until a reply is received or until the GTP 
entity has ceased retransmission of that message. The Sequence Number shall be unique for each outstanding Initial 
message sourced from the same IP/UDP endpoint. A node running GTP may have several outstanding messages waiting 
for replies. Not counting retransmissions, a single GTP message with an expected reply shall be answered with a single 
GTP reply, regardless whether it is per UE, per APN, or per bearer 

A piggybacked initial message (such as a Create Bearer Request message or Modify Bearer Request message) shall 
contain a Sequence Number that is assigned by sending GTP entity and the message shall be held in a list until a 
response is received. The response message to a piggybacked initial message may arrive without piggybacking (e.g.. 
Create Bearer Response at PGW). 

The Sequence Number in the GTP header of the triggered response message shall be copied from the respective request 
message. 

If a request message (e.g.. Create Session Request) triggers piggybacking (i.e.. Create Bearer Request piggybacked on 
Create Session Response), re-transmission of the request message shall also trigger piggybacking. A Sequence Number 
used for a Command message shall have the most significant bit set to 1 . A Sequence Number in a message, which was 
triggered by a Command message, as well as respective Triggered Reply message shall have the same Sequence 
Number as the Command message (i.e. shall also have the most significant bit set to 1). This setting of the most 
significant bit of the Sequence Number is done to avoid potential clashes between the Sequence Number selected for a 
Command message, and the Sequence Number selected by a GTPv2 peer for a Request message, which was not 
triggered by a Command message. 

A Sequence Number used for a Request message, which was not triggered by a Command message shall have the most 
significant bit set to 0. 

A timer, denoted T3-RESPONSE, shall be started when a signalling message (for which a reply is expected) is sent. A 
signalling message or the triggered message has probably been lost if a reply has not been received before the T3- 
RESPONSE timer expires. 

Once the T3-RESPONSE timer expires, the message corresponding to the T3-RESPONSE timer is then retransmitted if 
the total number of retry attempts is less than N3-REQUESTS times. The expiry of the timer for piggybacked request 
messages shall result in re-transmission of the original IP/UDP packet containing both the triggered response message 
and the piggybacked initial message. T3-RESPONSE timer and N3-REQUESTS counter setting is implementation 
dependent. That is, the timers and counters may be configurable per procedure. Multileg communications (e.g. Create 
Session Requests and Responses) however require longer timer values and possibly a higher number of retransmission 
attempts compared to single leg communication. 

All received GTPv2 messages with an expected reply shall be replied to and all reply messages associated with a certain 
message shall always include the same information. Duplicated reply messages shall be discarded by the receiver unless 
the reply needs a reply. A received reply message without a matching outstanding message that is waiting for a reply 
should be discarded. 

If a GTPv2 node is not successful with the transfer of a non-Echo signalling message, e.g. a Create Bearer Request 
message, it shall inform the upper layer of the unsuccessful transfer so that the controlhng upper entity may take the 
necessary measures. 
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7.7 Error Handling 

7.7.0 Handling Piggybacl^ed IVIessages 

For piggybacked initial messages, the following general rule shall apply: the triggered response message carrying the 
piggybacked message shall be processed first, according to the following sections. Subsequently, the piggybacked 
initial message shall be processed independently. If the processing of dedicated bearer activation message results in an 
error, this shall not affect the default bearer establishment. If the default bearer estabhshment fails, the dedicated bearer 
activation related message shall be discarded. 

7.7.1 Protocol Errors 

A protocol error is defined as a message or an Information Element received from a peer entity with unknown type, or if 
it is unexpected, or if it has an erroneous content. 

The term silently discarded is used in the following subclauses to mean that the receiving GTP entity's implementation 
shall discard such a message without further processing, or that the receiving GTP entity discards such an IE and 
continues processing the message. The conditions for the receiving GTP entity to silently discard an IE are specified in 
the subsequent subclauses. 

The handling of unknown, unexpected or erroneous GTP messages and lEs shall provide for the forward compatibility 
of GTP. Therefore, the sending GTP entity shall be able to safely include in a message a new conditional-optional or an 
optional IE. Such an IE may also have a new type value. Any legacy receiving GTP entity shall, however, silently 
discard such an IE and continue processing the message. 

If a protocol error is detected by the receiving GTP entity, it should log the event including the erroneous message and 
may include the error in a statistical counter. 

An information element with "Mandatory" in the "Presence requirement" column of a message definition shall always 
be present in that message. 

An information element with "Conditional" in the "Presence requirement" column of a message definition shall be sent 
when the conditions detailed in the "Presence requirement" are met. 

The Version Not Supported Indication message shall be considered as a Triggered message as specified in subclause 
4.2.5 "Messages with GTPv2 defined replies: Classification of Initial and Triggered Messages". 

The receiving GTP entity shall apply the error handling specified in the subsequent subclauses in decreasing priority. 

If the received erroneous message is a reply to an outstanding GTP message, the GTP transaction layer shall stop 
retransmissions and notify the GTP application layer of the error even if the reply is silently discarded. 

7.7.2 Different GTP Versions 

If a GTPv2 entity receives a message of an unsupported GTP version, higher than GTPv2, it shall return a Version Not 
Supported Indication message and silently discard the received message. 

If a GTPv2 entity listens to the GTPvO port, the entity shall silently discard any received GTPvO message. 

If a GTPv2 entity does not support GTPvl and receives a GTPvl message, it shall silently discard the received 
message. 

7.7.3 GTP IVIessage of Invalid Length 

If a GTP entity receives a message, which is too short to contain the respective GTPv2 header, the GTP-PDU shall be 
silently discarded. 

Apart from a piggybacked GTP message or an Echo Request message, if a GTP entity receives a Request message 
within an IP/UDP packet of a length that is inconsistent with the value specified in the Length field of the GTP header, 
then the receiving GTP entity should log the error and shall send the Response message with Cause IE value set to 
"Invalid Length". 
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Apart from a piggybacked GTP message, if a GTP entity receives a Response message within an IP/UDP packet of a 
length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity 
should log the error and shall silently discard the message. 

If a GTP entity receives two GTP messages (triggered response message and a piggybacked initial message) within an 
IPAJDP packet of a length that is inconsistent with the total length of the two concatenated messages as indicated by 
Length fields of the GTP headers, then the receiving GTP entity should log the error and return an appropriate Response 
message with Cause IE value set to "Invalid overall length of the triggered response message and a piggybacked initial 
message". That is: 

for a Create Session Response message together with a piggybacked Create Bearer Request message, a Create 
Bearer Response message should be returned with the above Cause value. 

- for a Create Bearer Response message together with a piggybacked Modify Bearer Request message, a Modify 
Bearer Response message should be returned with the above Cause value. 

7.7.4 Unknown GTP Message 

If a GTP entity receives a message with an unknown Message Type value, it shall silently discard the message. 

7.7.5 Unexpected GTP Message 

If a GTP entity receives an unexpected initial message (see subclause 4.2 "Protocol stack"), it shall be silently discard 
the message and shall log an error. 

If a GTP entity receives an unexpected triggered message (see subclause 4.2 "Protocol stack"), it shall discard the 
message and may log an error. 

7.7.6 Missing Information Elements 

A GTP entity shall check if all mandatory lEs are present in the received Request message. Apart from Echo Request 
message, if one or more mandatory information elements are missing in the received Request message, the GTP entity 
should log the error and shall send a Response message with Cause IE value set to "Mandatory IE missing" together 
with the type and instance of the missing mandatory IE. 

If a GTP entity receives a Response message with Cause IE value set to "Mandatory IE missing", it shall notify its 
upper layer. 

A GTP entity shall check if all mandatory lEs are present in the received Response message. If one or more mandatory 
information elements are missing, the GTP entity shall notify the upper layer and should log the error. 

A GTP entity shall check if conditional information elements are present in the received message, if possible (i.e. if the 
receiving entity has sufficient information available to check if the respective conditions were met). 

When possible, a GTP entity shall check if all conditional lEs are present in the received Request message. If one or 
more conditional information elements are missing, GTP entity should log the error and shall send a Response message 
with Cause IE value set to "Conditional IE missing" together with the type and instance of the missing conditional IE. 

When possible, a GTP entity shall check if all conditional lEs are present in the received Response message. If one or 
more conditional information elements are missing, GTP entity shall notify the upper layer and should log the error. 

If the Indication IE is applicable for the message as a conditional IE and if it is not present, the GTP entity shall not 
reject the message unless there are other reasons to reject the message. 

If the Indication IE is applicable for the message as conditional IE and if it is present with the value of all the applicable 
flags set to "0", the GTP entity shall not reject the message unless there are other reasons to reject the message. 

Absence of an optional information element shall not trigger any of the error handling processes. 



ETSI 



3GPP TS 29.274 version 11.5.0 Release 11 



134 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



7.7.7 Invalid Length Information Element 

An information element has invalid length when the actuiil length of the IE is different from the value of the Length 
field in the IE header. Here, the actual length of the IE means the length of the content field of the received IE. 

If a GTP message contains more than one information elements and one or more of them have invalid length, the 
receiving GTP entity can detect which of the lEs have invalid length only in the following cases: 

- If the Length value in the IE header is greater than the overall length of the message; 

- If the invahd length IE is the last one in the message. 

Apart from Echo Request message, if a receiving GTP entity detects information element with invalid length in a 
Request message, it shall send an appropriate error response with Cause IE value set to "Invalid length" together with 
the type and instance of the offending IE. 

Other Length field handling cases are specified below: 

- If the received value of the Length field and the actual length of the fixed length IE are consistent, but the length 
is greater than that expected by the fixed number of octets, then the extra octets shall be discarded. 

- If the received value of the Length field and the actual length of the fixed length IE are consistent, but the length 
is less than that expected by the fixed number of octets, this shall be considered an error, IE shall be discarded 
and if the IE was received as a Mandatory IE or a verifiable Conditional IE in a Request message, an appropriate 
error response with Cause IE value set to "Invalid length" together with the type and instance of the offending IE 
shall be returned to the sender. 

If the received value of the Length field and the actual length of the extendable length IE are consistent, but the 
length is greater than that expected by the fixed number of octets preceding the extended field(s), then the extra 
unknown octets shall be discarded. 

- If the received value of the Length field and the actual length of the extendable length IE are consistent, but the 
length is less than the number of fixed octets defined for that IE, preceding the extended field(s), this shall be 
considered an error, IE shall be discarded and if the IE was received as a Mandatory IE or a verifiable 
Conditional IE in a Request message, an appropriate error response with Cause IE value set to "Invalid length" 
together with the type and instance of the offending IE shall be returned to the sender. Please refer to Table 8.1-1 
for determining the number of fixed octets of an IE. 

7.7.8 Semantically incorrect Information Element 

Apart from Echo Request message, the receiver of a GTP signalhng message Request including a mandatory or a 
verifiable conditional information element with a semantically invahd Value shall discard the request, should log the 
error, and shall send a response with Cause set to "Mandatory IE incorrect" together with a type and instance of the 

offending IE. 

The receiver of a GTP signalling message Response including a mandatory or a verifiable conditional information 
element with a semantically invalid Value shall notify the upper layer that a message with this sequence number has 
been received and should log the error. 

If a GTP entity receives an information element with a value which is shown as reserved, it shall treat that information 
element as invahd and should log the error. If the invalid IE is received in a Request, and it is a mandatory IE or a 
verifiable conditional IE, the GTP entity shall send a response with Cause set to "Mandatory IE incorrect " together with 
a type and instance of the offending IE. 

The principle is: the use of reserved values invokes error handling; the use of spare values can be silendy discarded and 
so in the case of lEs with spare values used, processing shall be continued ignoring the spare values. 

The receiver of a GTP signalling message including an optional information element with a Value that is not in the 
range defined for this information element value shall discard this IE, but shall treat the rest of the message as if this IE 
was absent and continue processing. The receiver shall not check the content of an information element field that is 
defined as 'spare". 

All semantically incorrect optional information elements in a GTP signalling message shall be treated as not present in 
the message. 
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7.7.9 



Unknown or unexpected Information Element 



The receiver of a GTP message including an imexpected information element with known Type value, but with the 
instance value that is not defined for this message shall discard the IE and log an error. The receiver shall process the 

message. 

An information element with a Type value which is defined in section 8.1 of the present specification but whose 
Instance Value is not expected in the received GTP signalling message according to the grammar defined in section 7 
of the present specification shall be silently discarded (skipped) and the rest of the message processed as if this 
information element was not present. 

NOTE: An Information Element in an encoded GTPv2 message or grouped IE is identified by the pair of IE Type 



An Information Element is repeated if there is more than one IE with the same IE Type and Instance in the scope of the 
GTP message (scope of the grouped IE). Such an IE is a member in a Ust. 

If an information element is repeated in a GTP signalling message in which repetition of the information element is not 
specified, only the contents of the information element appearing first shall be handled and all subsequent repetitions of 
the information element shall be ignored. When repetition of information elements is specified, only the contents of 
specified repeated information elements shall be handled and all subsequent repetitions of the information element shall 
be ignored. 



7.7.11 TFT Error Handling 

TFT related error handling for EUTRAN is specified in 3GPP TS 24.301 [23] and for UTRAN/GERAN in 3GPP TS 
24.008 [5]. 



and Instance value. 



7.7.10 



Repeated Information Elements 



7.8 



Path Failure 



Path failure handling procedures are specified in 3GPP TS 23.007 [17]. 



7.9 



Restoration and Recovery 



7.9.0 



General 



Restoration and Recovery procedures are specified in 3GPP TS 23.007 [17]. 



7.9.1 



Delete PDN Connection Set Request 



This message may be sent on the S2a, S2b, S5, S8, or Sll interfaces as specified in 3GPP TS 23.007 [17]. 
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Table 7.9.1-1: Information Elements in a Delete PDN Connection Set Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


MME-FQ-CSID 


C 


This IE shall be included when a MME reports a partial 
fault according to the requirements in 3GPP TS 23.007 
[17]. More than one FQ-CSID may appear. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included when a SGW reports a partial 
fault according to the requirements in 3GPP TS 23.007 
[17]. More than one FQ-CSID may appear. 


FQ-CSID 


1 


PGW-FQ-CSID 


c 


Shall be included when a PGW reports a partial fault. More 
than one FQ-CSID may appear 


FQ-CSID 


2 


ePDG-FQ-CSID 


c 


This IE shall be included when an ePDG reports a partial 
fault according to the requirements in 3GPP TS 23.007 
[17]. More than one FQ-CSID may appear. 


FQ-CSID 


3 


TWAN-FQ-CSID 


c 


This IE shall be included when a TWAN reports a partial 
fault according to the requirements in 3GPP TS 23.007 
[17]. More than one FQ-CSID may appear. 


FQ-CSID 


4 


Private Extension 





NoneThis IE may be sent on the S2a, S2b, S5, S8 and 
S11 interfaces. 


Private Extension 


VS 



TEID of shall be used for the Delete PDN Connection Set Request. 

Only one type of FQ-CSID shall be included in each Delete PDN Connection Set Request, A mix of different types, 
such as SGW-FQ-CSID and PGW-FQ-CSID shall not be used. A combined node, such as a collocated PGW/SGW, 
shall send separate Delete PDN Connection Set Request for the PGW role and one for the SGW role if a partial fault 
impacts more than one role. 

7.9.2 Delete PDN Connection Set Response 

This message is sent as a response to the Delete PDN Connection Set Request. 



Table 7.9.2: Information Elements in a Delete PDN Connection Set Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 





This IE may be sent on the S2a, S2b, S5, S8 and S1 1 
interfaces. 


Private Extension 


VS 



TEID of shall be used for the Delete PDN Connection Set Response. 
The following Cause values are defined: 

"Request Accepted" 

"Request rejected" 

- "System failure". 

- "Mandatory IE incorrect". 
"Conditional IE missing". 
"InvaUd message format". 

"Request Accepted" indicates the receiving node was capable of storing a CSID value for each PDN coimection for the 
type of node (MME, SGW, PGW, TWAN or ePDG) in the Delete PDN Connection Set Request and has marked, or will 
mark immediately, the PDN connections for deletion as specified in 3GPP TS 23.007 [17]. "Request Accepted" shall be 
returned even if there are no PDN cormections that match. 

"Request rejected" shall be used when the receiver of the Delete PDN Coimection Set Request is not capable of storing 
at least one CSID value per PDN connection for the type of node (MME, SGW, PGW, TWAN or ePDG) received in the 
Delete PDN Coimection Set Request. 
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The SGW shall respond to the Delete PDN Connection Set Request independently, i.e. without waiting for repUes. 

7.9.3 Update PDN Connection Set Request 

The SGW shall send this message to the PGW on S5/S8 according to the requirements in TS 23.007 [17]. 



Table 7.9.3-1 : Information Elements in a Update PDN Connection Set Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


MME-FQ-CSID 


C 


Tiiis iE stiaii be inciuded for iVIiVIE reiocation wittiout SGW 
relocation according to ttie requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included for W\W\E relocation without SGW 
relocation according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 


1 


Private Extension 







Private Extension 


vs 



7.9.4 Update PDN Connection Set Response 

This message is sent by the PGW to the SGW on S5/S8 in response to the Update PDN Connection Set Request 
message. 



Table 7.9.4-1 : Information Elements in a Update PDN Connection Set Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





PGW-FQ-CSID 





This IE shall be included for MME relocation without SGW 
relocation according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 





Private Extension 







Private Extension 


VS 



The following Cause values are defined: 
"Request accepted" 
"Request rejected" 
- "System failure". 

"Mandatory IE missing". 
"Invalid message format". 

7.9.5 PGW Restart Notification 

The direction of this message shall be from SGW to MME/S4-SGSN (see Table 6.1-1). 

If both the SGW and the MME/S4-SGSN support the PRN feature (see subclause 8.83), a PGW Restart Notification 
shall be sent when the SGW detects that the peer PGW has restarted, and a PGW Restart Notification may be sent when 
the SGW detects that the peer PGW has failed and not restarted, as specified in 3GPP TS 23.007 [17]. 

Table 7.9.5-1 specifies the presence of lEs in this message. 
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Table 7.9.5-1 : Information Elements in PGW Restart Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


PGW S5/S8 IP 
Address for Control 
Plane or PMIP 


IVI 




IP Address 





SGW S11/S4 IP 
Address for Control 
Plane 


M 




IP Address 


1 


Cause 


CO 


The SGW shall send the Cause IE with the value "PGW 
not responding" if it sends the PGW Restart Notification to 
notify that the peer PGW has failed and not restarted. 


Cause 





Private Extension 







Private Extension 


vs 



7.9.6 PGW Restart Notification Acknowledge 

The PGW Restart Notification Acknowledge shall be sent as a response of PGW Restart Notification to indicate that the 
MME/S4-SGSN deletes all the relevant PDN connections as specified in 3GPP TS 23.007 [17] if the Cause IE includes 
an acceptance cause. 

Possible Cause values are specified in Table 8.4-1. 



Table 7.9.6-1 : Information Elements in PGW Restart Notification Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 



7.9.7 PGW Downlink Triggering Notification 

The direction of this message shall be from PGW to SGW and from SGW to MME(s)/S4-SGSN(s). 

The PGW Downlink Triggering Notification shall be sent as part of the PGW triggered SGW restoration procedure if 
the MME/S4-SGSN, SGW and PGW support this optional feature as specified in 3GPP TS 23.007 [17]. 



Table 7.9.7-1 : Information Elements in PGW Downlink Triggering Notification 



Information 


P 


Condition / Comment 


IE Type 


Ins. 


elements 










IMSI 


M 




IMSI 





MME/S4-SGSN 


C 


This IE shall be included over S5 /S1 1/S4 interface as 


IP Address 





identifier 




specified in 3GPP TS 23.007 [17]. 






Sender F-TEID for 
Control Plane 





This IE may be included over the S5 interface. If present, it 
shall contain the PGW S5 F-TEID value assigned during 
the PDN connection establishment. 
(NOTE 1) 


F-TEID 





Private Extension 







Private Extension 


vs 


NOTE 1 : The SGW shall set the header TEID value in the PGW Downlink Triggering Acknowledge to the 
PGW's Control Plane TEID if the Sender F-TEID for Control Plane IE is present in the PGW 




Downlink Triggering Notification message. 







7.9.8 PGW Downlink Triggering Acknowledge 

The PGW Downlink Triggering Acknowledge message shall be sent as a response to a PGW Downlink Triggering 
Notification message if the MME/S4-SGSN, SGW and PGW support the PGW triggered SGW restoration feature as 
specified in 3GPP TS 23.007 [17]. 

Possible Cause values are specified in Table 8.4-1. Message specific cause values are: 



ETSI 



3GPP TS 29.274 version 1 1 .5.0 Release 11 1 39 ETSI TS 1 29 274 V1 1 .5.0 (201 3-01 ) 

"Request accepted". 
- "Context not found". 



Table 7.9.8-1 : Information Elements in PGW Downlink Triggering Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





IMSI 


C 


Tliis IE sfiall be included on S1 1/S4 interface if the Cause 
is indicating the rejection value "Context Not Found" and if 
the MME/S4-SGSN identifier is included in the 
corresponding PGW Downlink Triggering Notification 

message. 


IMSI 





MME/S4-SGSN 
identifier 


C 


This IE shall be included on S1 1/S4 interface if the Cause 
is indicating the rejection value "Context Not Found" and if 
the MME/S4-SGSN identifier is included in the 
corresponding PGW Downlink Triggering Notification 
message. 


IP Address 





Private Extension 







Private Extension 


vs 



7.10 Fallback to GTPv1 mechanism 

An EPC entity shall assume that each GTP processing node that it is about to communicate with is GTPv2 capable. 
Before the first GTP tunnel is setup for a given UE/node, the EPC node shall always send a version 2 (GTPv2) message 
to a peer node. As an exception, during an inter-SGSN handover, even if the target SGSN is GTPv2 capable, the source 
SGSN shall send a GTPvl message "Forward Relocation Request" to the target SGSN if the PDP Context(s) for this UE 
were established to GGSN(s), or if there is no active PDP context and the source or target SGSN does not support 
SRNS relocation w/o PDN connection over GTPv2 (see subclause 7.3.1). 

A GTPv2 entity shall fallback to GTPvl only if either a "Version Not Supported" message in GTPvl format as 
specified in 3GPP TS 29.060 [4] is received from the peer node (this indicates that the peer GTP entity does not support 
GTPv2), or if a GTPv2 message is received with Cause value "Fallback to GTPvl". 

If a GTPvl "Version Not Supported" message in received, a GTPv2 entity may fallback to GTPvl. 3GPP TS 23.401 [3] 
(see annex D) and 3GPP TS 23.060 [35] specify GTP version usage during the mobility between a UTRAN/GERAN 
and an E-UTRAN. 

A GTPv2 entity may receive a GTPv2 message with a Cause value "Fallback to GTPvl" in the following cases: 

an S4 SGSN receives the Cause code "Fallback to GTPvl" in a GTPv2 Context Response message over S16 
interface. When an UE has activated a PDP context via S4 SGSN to GGSN and inter-SGSN RAU is underway, 
the old S4 SGSN shall include the Cause value "Fallback to GTPvl" in a GTPv2 Context Response message 
over S16 interface. In this case, the new S4 SGSN shall abort the ongoing GTPv2 procedure and send a GTPvl 
"SGSN Context Request" message to the old S4 SGSN. The fallback to GTPvl is performed only for this UE in 
the current procedure. 

an MME receives the Cause code "Fallback to GTPvl" in a GTPv2 Context Response message over the S3 
interface. When an UE has active PDP context(s) via an S4 SGSN and a TAU is underway, the old S4 SGSN 
may include the Cause value "Fallback to GTPvl" in a GTPv2 Context Response message over the S3 interface. 
In this case, the MME shall abort the ongoing GTPv2 procedure and should send a GTPvl "SGSN Context 
Request" message to the old S4 SGSN. The fallback to GTPvl is performed only for this UE. 

Fallback to GTPvl shall not occur on already established GTP tunnels without change of the peer nodes of the 
communication bearer. 

7.11 Fallback to GTPvO 

Fallback from GTPv2 to GTPvO shall not be supported. Therefore, GTPv2 entity should not listen to the well-known 
GTPvO port 3386. 



ETSI 



3GPP TS 29.274 version 11.5.0 Release 11 



140 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



7.12 Trace Management Messages 
7.12.1 Trace Session Activation 

The Trace Session Activation message shall be sent on SI 1/S4 by the MME/SGSN to the SGW, on S2a/S2b by the 
TWAN/ePDG to the PGW, and on S5/S8 by the SGW to the PGW when session trace is activated for a particular IMSI 
or IMEI for a UE that is attached and active or attached and idle. 

Table 7.12.1-1 specifies the presence of the lEs in the message. 



Table 7.12.1-1 : Information Elements in a Trace Session Activation 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


C 


The MME/SGSN shall include the IMSI in the message on 
the S1 1/S4 interface except for the case: 

- If the UE is emergency attached and the UE is 
UlCCIess. 

The IMSI shall be included in the message on the S1 1/S4 
interface but not used as an identifier 

if UE is emergency attached but IMSI is not 

authenticated. 

The SGW shall forward this IE to the PGW on S5/S8 if 
received on S1 1/S4. 

The TWAN/ePDG shall include this IE on the S2a/S2b 
interface. 


IMSI 





Trace Information 


M 




Trace Information 





ME Identity (MEI) 


C 


The MME/SGSN shall include the ME Identity (MEI) IE on 
the S11/S4 interface: 

- If the UE is emergency attached and the UE is 
UlCCIess 

- If the UE is emergency attached and the IMSI is not 
authenticated 

In other cases, the MME shall include the ME Identity 
(MEI) IE on the S1 1 interface, if available. 

The SGW shall forward this IE to the PGW on S5/S8 if 
received on S1 1/S4. 


MEI 






7.12.2 Trace Session Deactivation 

The Trace Session Deactivation message shall be sent on SI 1/S4 by the MME/SGSN to the SGW, on S2a/S2b by the 
TWAN/ePDG to the PGW, and on S5/S8 by the SGW to the PGW when session trace is deactivated for a particular 
IMSI or IMEI for a UE that is attached and active or attached and idle. 

Table 7.12.2-1 specifies the presence of the lEs in the message. 



Table 7.12.2-1 : Information Elements in a Trace Session Deactivation 



Information 

elements 


P 


Condition / Comment 


IE Type 


Ins. 


Trace Reference 


M 




Trace Reference 
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7.13 MBMS Messages 

7.1 3.1 MBMS Session Start Request 

The MBMS Session Start Request message shall be sent on the Snn/Sn interface by the MBMS GW to the MME/SGSN 
as specified in 3GPP TS 23.246 [37]. 

Table 7.13.1-1 specifies the presence of the lEs in the message. 



Table 7.13.1-1: Information Elements in a MBMS Session Start Request 



Information 

1 1 1 1 ^/ III 1041^/1 1 

elements 


p 


Condition / Comment 

1 IVI 1 H^^l 1 1 ^^^^1 1 1 1 1 1 Wl 1 1 


IE Type 


Ins. 


Qpnrlpr F-TFID fnr 
Control Plane 


M 




F-TEID 


n 


Temporary Mobile 
firniin Irlpntitv ^TMGh 


M 




TMGI 





IVIRM.9 Spt;<;inn 
Duration 


M 




MRMS .^pssinn 
Duration 





MBMS Service Area 


M 




MBMS Service 
Area 





MBMS Session 
Identifier 


C 


Tflis IE sliall be forwarded to MME/SGSN if it is provided 
by the BM-SC. 


MBMS Session 
Identifier 





MBMS Flow Identifier 


C 


This IE shall be forwarded to MME/SGSN if it is provided 

by the BM-SC. 


MBMS Flow 

Identifier 





QoS profile 


M 


See NOTE 1 . 


Bearer OoS 





MBMS IP Multicast 
Distribution 


M 




MBMS IP 
Multicast 
Distribution 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





MBMS Time to Data 
Transfer 


CO 


This IE shall be forwarded to MME/SGSN if it is received 
from the BM-SC. 


MBMS Time to 
Data Transfer 





MBMS Data Transfer 
Start 


CO 


This IE shall be forwarded to the MME if it is received from 
the BM-SC. 


Absolute Time of 
MBMS Data 
Transfer 





Private Extension 







Private Extension 


VS 


NOTE 1 : The uplink GBR and uplink MBR shiall be ignored by MME/SGSN as specified in Section 20.5 of 
3GPP TS 29.061 [38]. 



7.1 3.2 MBMS Session Start Response 

The MBMS Session Start Response message shall be sent as a response to the MBMS Session Start Request message 
on the Sm/Sn interface by the MME/SGSN to the MBMS GW. 

Table 7.13.2-1 specifies the presence of the lEs in the message. 

Possible Cause values are specified in Table 8.4-1. 
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Table 7.13.2-1 : Information Elements in a MBMS Session Start Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Sender F-TEID for 
uoniroi riane 


M 




F-TEID 





MBMS Distribution 
Acknowledge 


C 


This IE sliall be included on the Sn interface. 


MBMS 
Distribution 
Acknowledge 





Sn-U SGSN F-TEID 


c 


This IE shall be included on the Sn interface if some RNCs 
have not accepted IP multicast distribution. 


F-TEID 


1 


Recovery 


c 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


VS 



7.1 3.3 MBMS Session Update Request 

The MBMS Session Update Request message shall be sent on the Sm/Sn interface by the MBMS GW to the 
MME/SGSN as specified in 3GPP TS 23.246 [37]. 

Table 7.13.3-1 specifies the presence of the lEs in the message. 



Table 7.13.3-1: Information Elements in a MBMS Session Update Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


MBMS Service Area 


C 


This IE shall be forwarded to MME/SGSN if it is provided 
by the BM-SC. 


MBMS Service 
Area 





Temporary Mobile 
Group Identity (TMGI) 


M 




TMGI 





Sender F-TEID for 
Control Plane 







F-TEID 





MBMS Session 
Duration 


M 




MBMS Session 
Duration 





QoS profile 


M 


See NOTE 1 . 


Bearer QoS 





MBMS Session 
Identifier 


C 


This IE shall be fonwarded to MME/SGSN if it is provided 
by the BM-SC. 


MBMS Session 

Identifier 





MBMS Flow Identifier 


C 


This IE shall be forwarded to MME/SGSN if it is provided 
by the BM-SC. 


MBMS Flow 
Identifier 





MBMS Time to Data 
Transfer 


CO 


This IE shall be forwarded to MME/SGSN if it is provided 
by the BM-SC. 


MBMS Time to 
Data Transfer 





MBMS Data Transfer 
Start 


CO 


This IE shall be forwarded to the MME if it is received from 
the BM-SC. 


Absolute Time of 
MBMS Data 
Transfer 





Private Extension 







Private Extension 


VS 


NOTE 1 : The uplink GBR and uplink MBR shall be ignored by MME/SGSN as specified in Section 20.5 of 
3GPP TS 29.061 [38]. 



7.13.4 MBMS Session Update Response 

The MBMS Session Update Response message shall be sent as a response to the MBMS Session Update Request 
message on the Sm/Sn interface by the MME/SGSN to the MBMS GW. 

Table 7.13.4-1 specifies the presence of the lEs in the message. 

Possible Cause values are specified in Table 8.4-1. 
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Table 7.13.4-1 : Information Elements in a MBMS Session Update Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


IVI 




Cause 





MdMo UlSTilDUIIOn 

Acknowledge 


Li 


— — — — — - — — — — : — ^ — : : 

This IE siiall be included on the Sn interface if service area 
is changed. 


MDMO 

Distribution 
Acknowledge 


U 


Sn-U SGSN F-TEID 


c 


This IE shall be included on the Sn interface if any of the 
newly added RNCs have not accepted IP multicast 
distribution. 


F-TEID 





Recovery 


c 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 



7.1 3.5 MBMS Session Stop Request 

The MBMS Session Stop Request message shall be sent on the Sm/Sn interface by the MBMS GW to the MME/SGSN 
as specified in 3GPP TS 23.246 [37]. 

Table 7.13.5-1 specifies the presence of the lEs in the message. 



Table 7.13.5-1: Information Elements in a MBMS Session Stop Request 



Info specified in 
Table 8.4-1 .rmation 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


MBMS Flow Identifier 


C 


This IE shall be forwarded to MME/SGSN if it is provided 
by the BM-SC. See NOTE 1 . 


MBMS Flow 
Identifier 





MBMS Data Transfer 
Stop 


CO 


This IE shall be fonwarded to the MME if it is received from 
the BM-SC. 


Absolute Time of 
MBMS Data 
Transfer 





Private Extension 







Private Extension 


VS 


NOTE 1 : The conditional MBMS Flow Identifier IE is redundant as MBMS Session Stop Request message is 
sent over non-zero TEID header. The receiver may ignore the MBMS Flow Identifier IE. 



7.13.6 MBMS Session Stop Response 

The MBMS Session Stop Response message shall be sent as a response to the MBMS Session Stop Request message on 
the Sm/Sn interface by the MME/SGSN to the MBMS GW. 

Table 7.13.6-1 specifies the presence of the lEs in the message. 

Possible Cause values are are specified in Table 8.4-1. 



Table 7.13.6-1 : Information Elements in a MBMS Session Stop Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 


CO 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


VS 
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8 



GTP-C Information Elements 



8.1 



Information Element Types 



A GTP control plane (signalling) message may contain several information elements. In order to have forward 
compatible type definitions for the GTPv2 information elements, all of them shall be TLIV (Type, Length, Instance, 
Value) coded. GTPv2 information element type values are specified in the Table 8.1-1. The last column of this table 
indicates whether the information element is: 

- Fixed Length: the IE has a fixed set of fields, and a fixed number of octets. 

Variable Length: the IE has a fixed set of fields, and has a variable number of octets. 

For example, the last octets may be numbered similar to "5 to (n+4)". In this example, if the value of the length 
field, n, is 0, then the last field is not present. 

- Extendable: the IE has a variable number of fields, and has a variable number of octets. 

The last fields are typically specified with the statement: "These octet(s) is/are present only if explicitly 
specified". The legacy receiving entity shall ignore the unknown octets. 

In order to improve the efficiency of troubleshooting, it is recommended that the information elements should be 
arranged in the signalling messages as well as in the grouped IBs, according to the order the information elements are 
listed in the message definition table or grouped IE definition table in section 7. However the receiving entity shall be 
prepared to handle the messages with information elements in any order. 

Within information elements, certain fields may be described as spare. These bits shall be transmitted with the value set 
to 0. To allow for future features, the receiver shall not evaluate these bits. GTPv2-C information elements that have 
similar semantics in GTPvl-C shall be converted into GTPvl-C format, as specified in TS 29.060 [4], before sending 
them to a pre-R8 GSN. 
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Table 8.1-1 : Information Element types for GTPv2 



IE Type 


information elements 


Comment / Reference 


Number of Fixed Octets 


value 



















Intprn^tinriTil Mohilp ^iihQrrihpr IHpntitv MM^h 

III 1^1 1 IQllvJI ICll IvIWk/llw LI KjiD\y 1 llk/^l lUwIlllly V 1 1 VI v.^ 1 1 


Varlahlp 1 pnnth 7 8*^ 


NInt Annlirahip 

iN^jL r^^|_(iit..(dik/ic 


2 


(^p 1 icp 


\/priphlp I pnnth / R 4 


Nnt Af^nlipahlp 

iNWi nufji iLidkJic 


3 




V di idui c I— CI ly LI 1 / o. o 


INUl rAjJ^JilUdUIC 


4 to 50 


Rpcprv/Qrl fnr ^1 fll intprfar'P 

ilCOCI VCVJ lUi O 1 v./ 1 II ILCI IClLiC 


Qpp "^RPP T'? ?Q P7R [1 41 


'^pp '^fiPP ?Q ?7fi n 41 


51 


STN-SR 

\J 1 1 ^ Vw/ 1 I 


Spp "^GPP T5? 29 280 11 51 


5?pp ?GPP TS 29 280 11 51 


52 to 70 


RpQprvpH fnr .^v intprfarp 


Spp ^GPP TR 2q 280 11 51 


Spp ^GPP TS 29 280 11 51 


j-\ 


ArrpQ9 Point Namp I'APNJ^ 

/^^o^oo 1 Willi iNdiii^ V'*' / 


Varlahlp 1 pnnth / ft fi 
V di iduic I— d lyLi 1 / 


Mnt Annlirahip 

i>iUL r^ijkyiiv.idi.'ic 


72 


Annrc^rm^p' MnYimiim Rit Rntp ^AMRR^ 
rtyyicyaLC iviaAii i lui 1 1 oil rictic ^rtivion^ 


FiYPd 1 pnnth / ft 7 


3 


73 


FP9 Rparpr ID ^FRh 


Fytpndahip / ft ft 

^AlCl lUdUIC / O.O 


"1 


74 


IP Addrp^*; 

II /^VJ U 1 


Varlahlp 1 pnnth / ft Q 
v di idkjic I— d lyLi 1 / u . -J 


Nnt Annlirahip 


75 


Mnhilp Fniiinmpnt IHpntitu flV^Fh 

1 VI kj 1 1 ^ ^ULJ 1 k^lll^lll IkJ^llllly 1 1 VI ^ 1 1 


Varlahlp 1 pnnth / ft 10 
V di idkjic 1— d lyLi 1 / u> 1 \j 


Nnt Annlirahip 


76 


1 VIO 1 O l-fi ^ 


Varlahlp 1 pnnth / ft 1 1 
V di iduic 1— d ly LI 1 / o> 1 1 


Mnt Annlirahip 


77 


InHir'atinn 
II luiodiiui 1 


FvtpnHahlp 1 R ^9 

^ALCI lUdlk/IC / O. 1^ 


2 


78 




Varlahlp 1 pnnth / RIT 
V di idL/ic 1— CI ly 11 1 / O- 1 o 


Mnt Artnlirahlp 

INUL AA|J|JIILrdUIC 


79 


PDN AHHrpcic Allnratinn /'PAA') 

1 1 >l rAi_IHICOo ni lULiClLI Wl 1 \\ r\r\l 


Variahip 1 pnnth / ft 14 

VdlldLJIC LCIIULII / U. Pt^ 


Mnt Annlirahip 


80 


Rparpr 1 p\/pI Oii3lit\/ nf '--Ipn/ipp /Rp^rpf 00*-^^ 
Ljcdi CI i—cvci VjfUciiiiy \J\ odvn./c; luccii ci Vjiuoi 


FytpnrJahlp / ft 1 S 

^AlCI lUdUIC / O. 1 O 


22 


81 




Fvtpnriahlp / 8 Ifi 

^ALCrl lUdUICr / O. 1 \J 


21 


82 


RAT Tvnp 

nrA 1 1 y [jc 


Fvtpndahlp / 8 17 

^ALCI lUdlk^lC / O. 1 / 


"1 


83 


.^prvinn Nptwnrk 

VII ly iNCLVvwiix 


Fxtpndahip / ft 1 R 

1 — AICI IVjdkJIC / \J. 1 \J 


3 


84 


FP^ Rpnrpr 1 p\/pI Trpffin FInw Tpmnlntp /Rp^rpr TFT^ 
1 no i-'Cdi d 1— c vd iidiiiu 1 ivjvv icii iijidic v i_/Cdi d i i i i 


Varlahlp 1 pnnth / ft 1Q 
V di idUit:? 1— ci lyu 1 / o. 1 '3 


Nnt Annlirahip 

INUI rA[J[JI l^dUIC 


85 


Trnffin Annrpnntinn DpQnrintinn /TAn\ 


Varlahlp 1 pnnth / ft PO 
VdiidUic 1— diyiii / 


Nnt Annlirahip 


86 


1 l^^pr 1 nnatinn Infnrmatinn ([ II h 

1— ut^diitji 1 II iiui 1 1 idiitji 1 ^v^i— ly 


Fxtpndahlp / 8 21 

1 — /vlCI lUdkJIC / \J.C- 1 


"f+4-4" (Spp Finiirp 8 21-1') 


87 


Fiillv Oimlifiprl Tiinnpl Fnrlnnint IHpntifipr ^F-TFIR^ 

1 U 1 1 y Vj<Lldl 1 1 1 wvj 1 Lll 1 1 lul 1— 1 lUL^wl 1 IL I^JwIILIIIwl II 1 1— 1 i— / 1 


Extpndablp / 8 22 


9/21/25 


88 


TMSI 


Varlahlp 1 pnnth / ft P'^ 
VdiidUic? i—ciiyLii / o.^o 


Nnt Annlirahip 


89 


filnhal CN-ld 


Varlahlp 1 pnnth / ft P4 
VdiidUic 1— diyiii / Kj.^'-T 


Nnt Annlirahip 


90 


S10? PDN Data Forwardinn Infn ^55103PDF^ 

\w7 1 \J\J 1 1 i| 1— /C^Ld 1 \Jl VVdl xJI 1 IM 1 1 1 1 1 1 1 f 


Variahip L pnnth / 8 P'S 

V di idi^ic i_ci lyii 1 / 


Nnt Annlirahip 

IxVJL r^L/l_fllvydL/IC 


91 


91-11 Data Fnrwarriinn Infn /milDF^ 
o 1 \j Lycxid nui wdi uii ly ii iiu i vjlji j 


Varlahlp 1 pnnth/ 8 ?fi 


Mnt Annlirahip 

IvUL rA|J|JIILfdUIC 


92 


DpIsw Wall IP 
ucidy vdiuc 


FxtpnHahIp / 8 27 




93 


tJCdl \S\ \J\J\ 1 LCAL 


FxtpnHahIp / 8 ?R 


Mnt Annlirahip 
ivUL n|j|jiiLfduic 


94 


Oharninn ID 

wiidiyiiiy 1 i-f 


Extpndahip / 8 29 


4 


95 


Charging Characteristics 


Extendable / 8.30 


2 


3D 


1 I dOc 1 1 IIUI 1 1 IdLIUI 1 


\/artahlp 1 pnnth / 8 '51 
VdlldlJlc LUliyui / O.O 1 


IMUL r\ppilUdUiC 


Q7 


Dcdl tJI riciyb 


FytpnHnhlp / ft '^P 
CAlfcJi lUdUlt; / O.O^ 


1 


oo 


ncbcl vcU 






99 


PDN Type 


Extendable / 8.34 


1 


1 uu 


Procedure Transaction ID 


txienoaDie / o.oo 


1 


101 


Reserved 








Reserved 






103 


MM uontext (CjbM Key ana i ripiets) 


bxtenaaDle / o.oo 


r+1 -4 (bee rigure o.oo-i ) 


1U4 


iviivi L/Ontext (UM 1 b f\Qy, used oiprier ana 

fi r iirrlr ir"sl^!\+"C*\ 
WUIIIlUpicLby 


bxtenaaDle / o.oo 


r+1 -4 (bee rigure o.oo-i:) 


-I ni^ 


IVIIVI L-oniexi t^ooivi rvey, useu L/ipner dna Ljuiniupieis) 


txienuaDie / o.oo 


r+ 1 -4 t^oee rigure o.oo-oj 


1 UD 


IVIIVI ooniexi ^uivi i o r\ey ana Voiuintupieis^ 


txienadOie / o.oo 


r+ 1 -4 (oee rigure o.oo-4j 


1 A7 

lU/ 


MM Context (EPS SGCurity Context, Quadruplets and 

liri'l'i ir\lAtc\ 
WUil ILUpic;lb/ 


txtenaaoie / o.oo 


S+D4-4 (oee rigure o.oo-oj 


1 uo 


KAKA Pnntpvt {\ I^^TQ K'px/ Oi laHri inlp+c nnH 
IVIIVI OUIILcAl ^UIVI 1 O i\cy, WUdUIU|JlcLb dllU 

Oi linti inlptQ^ 

WUII 1 lUjJlc; Lb^ 


FYtpnrlahIp / ft '^8 
caici lUdUic / o.oo 


"rj.1-4" ^Qpp Finiirp ft '^8-8\ 
1+ 1 H ^Oct; riyUlc O.OO 


1 09 


PDN nnnnpntinn 

1 1 >l Wl II l^wllWI 1 


Fxtpndahlp / 8 '^Q 

1 — ALd lUdkJIC / \J.\J\J 


Nnt Annlirahip 

1 "iwi r^|j[..^i iv^duic 


1 10 


PHI 1 NiimhprQ 

1 1— / \j i>iuiiiucio 


FYtpndahIp / 8 40 


9 


1 1 1 


P-TMSI 


Varlahlp 1 pnnth / 8 41 

V di idui^ 1— c^iiyLii/ u.^i 


Nnt Annlirahip 


1 12 


P-TM'^l "^innatiirp 

1 1 ivioi ■JiyiidLUic 


Varlahlp 1 pnnth / 8 4P 

V dl IdUIC? 1— CI ly LI ! / O.'-r^ 


Nnt Annlipahip 

IMUL n|J|JIIUCtL/IC 


1 13 


Hnn r^.niintpr 


Fxtpndahlp / 8 4*^ 

^AlCl lUdUlC / O.T^O 


•j 


1 14 


1 IF Timp 7nnp 

1 1 1 1 1 1 C ^\Jl lU 


Fvtpndahlp / 8 44 

1 — Aid 1 VJdkJI C; ; tJ.T^T^ 


2 


115 


Trapp Rpfprpnpp 

1 1 1 ICI d d l\.fC 


FiypH 1 pnnth / 8 4R 

1 lACU 1— d lyil 1 / KJ-^\J 


Q 


116 


Onmnlptp RpniiPQt Mp^Qanp 

wuiiiL/idc 1 icuucoL ivicooayc 


Varlahlp 1 pnnth / 8 4R 

V dl IdL/IC 1— d lULI 1 / U-^U 


Nnt Annlipahip 


117 


GUTi 


Varlahlp 1 pnnth / 8 47 
vdiiduic i—ciiyiii/ o.^i 


Nnt Annlipahip 


118 


P-f^nntnin&r 

1 WUI lldll ICI 


Varlahlp 1 pnnth / 8 48 
V dl iduic 1— CI ly 11 1 / o.^o 


Nnt Annlipahip 

IMUL AA^|JIIUCll>./IC 


119 


F-Cause 


Variable Lengtfi / 8.49 


Not Applicable 


120 


PLMN ID 


Variable Lengtfi / 8.50 


Not Applicable 


121 


Target Identification 


Variable Lengtfi / 8.51 


Not Applicable 


122 


Reserved 






123 


Packet Flow ID 


Variable Length / 853 


Not Applicable 


124 


RAB Context 


Fixed Length / 8.54 


9 


125 


Source RNC PDCP Context Info 


Variable Length / 8.55 


Not Applicable 


126 


UDP Source Port Number 


Extendable / 8.56 


2 


127 


APN Restriction 


Extendable / 8.57 


1 


128 


Selection IWIode 


Extendable / 8.58 


1 
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IE Type 


Information elements 


Comment / Reference 


Number of Fixed Octets 


value 








(Decimal) 








129 


Source Identification 


Variable Length / 8.59 


Not Applicable 


130 


Reserved 






131 


Change Reporting Action 


Variable Length / 8.61 


Not Applicable 


132 


Fully Qualified PDN Connection Set Identifier (FQ- 
CSID) 


Extendable / 8.62 


"q+-| -4" (See Figure 8.62-1 ) 


133 


Channel needed 


Variable Length / 8.63 


Not Applicable 


134 


eMLPP Priority 


Variable Length / 8.64 


Not Applicable 


135 


Node Type 


Extendable / 8.65 


1 


136 


Fully Qualified Domain Name (FQDN) 


Variable Length / 8.66 


Not Applicable 


137 


Transaction Identifier (Tl) 


Variable Length / 8.68 


Not Applicable 


138 


MBMS Session Duration 


Extendable / 8.69 


3 


139 


IVIBMS Service Area 


Variable Length / 8.70 


Not Applicable 


140 


IVIBMS Session Identifier 


Extendable / 8.71 


1 


141 


IVIBMS Flow Identifier 


Extendable / 8.72 


2 


142 


IVIBMS IP Multicast Distribution 


Extendable / 8.73 


"m+1-4" (See Figure 8.73-1) 


143 


MBMS Distribution Acknowledge 


Extendable / 8.74 


1 


144 


RFSP Index 


Fixed Length / 8.77 


2 


145 


User CSG Information (UCI) 


Extendable / 8.75 


8 


146 


CSG Information Reporting Action 


Extendable / 8.76 


1 


147 


CSG ID 


Extendable / 8.78 


4 


148 


CSG Membership Indication (CMi) 


Extendable / 8.79 


1 


149 


Service indicator 


Fixed Length / 8.80 


1 


150 


Detach Type 


Fixed Length / 8.81 


1 


151 


Local Distiguished Name (LDN) 


Variable Length / 8.82 


Not Applicable 


152 


Node Features 


Extendable / 8.83 


1 


153 


MBMS Time to Data Transfer 


Extendable / 8.84 


1 


154 


Throttling 


Extendable / 8.85 


2 


155 


Allocation/Retention Priority (ARP) 


Extendable / 8.86 


1 


156 


EPC Timer 


Extendable / 8.87 


1 


157 


Signalling Priority Indication 


Extendable / 8.88 


1 


158 


Temporary Mobile Group Identity (TMGI) 


Extendable / 8.89 


6 


159 


Additional MM context for SRVCC 


Extendable / 8.90 


"e-4" (See Figure 8.90-1 ) 


160 


Additional flags for SRVCC 


Extendable / 8.91 


1 


161 


Reserved 






162 


MDT Configuration 


Extendable / 8.93 


"q-4" (See Figure 8.93-1) 


163 


Additional Protocol Configuration Options (APCO) 


Extendable / 8.94 


"m-4" (See Figure 8.94-1 ) 


164 


Absolute Time of MBMS Data Transfer 


Extendable / 8.95 


8 


165 


H(e)NB Information Reporting 


Extendable / 8.96 


1 


166 


IPv4 Configuration Parameters (IP4CP) 


Extendable / 8.97 


5 


167 


Change to Report Flags 


Extendable / 8.98 


1 


168 


Action Indication 


Extendable / 8.99 


1 


169 


TWAN Identifier 


Extendable/ 8.1 00 


"m-4" (See Figure 8.100-1) 


1 70 to 254 


Spare. For future use. 






255 


Private Extension 


Vahable Length / 8.67 


Not Applicable 


N0TE1 : The size of the TLI (Type, Length and Instance) fields, i.e "4" octets, has been subtracted from the number of the fixed 

octets of the "Fixed Length" and "Extendable" IBs. Hence for some of the "Extendable" lEs, for which the length is defined in 
terms of variable number of octets, "4" is explicitly subtracted while defining the fixed number of octets. E.g. Length of User 
Location Information is defined as "f+4" and fixed number of octets for the same is defined as "f+4-4". 



8.2 Information Element Format 
8.2.1 General 

Figure 8.2-1 depicts the format of an information element. 



Octets 


Bits 

8 7 6 5 4 3 2 1 


1 


Type = XXX (decimal) 




2to3 


Length = n 




4 


Spare Instance 




5 to (n-i-4) 


IE specific data or content of a grouped IE 





Figure 8.2-1 : Information Element Format 



An IE has the following mandatory fields: 
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- Type field: This field indicates the type of Information Element. The valid values of the IE type are defined in 
clause 8.1. 

- Length: This field contains the length of the information element excluding the first four octets, which are 
common for all information elements (Type, Length and the contents of octet 4) and is denoted "n" in Figure 8.2- 
1 . For all the length fields, bit 8 of the lowest numbered octet is the most significant bit and bit 1 of the highest 
numbered octet is the least significant bit. 

- Instance: This field shall be used to differentiate amongst different parameters in one specific message which use 
the same information element type (see also subclause 6.1.3 "Information Element Instance"). 

An IE is said to be TLIV (Type, Length, Instance, Value) encoded. 



8.2.2 Handling ASN.1/PER encoded parameters 

During the TAU/RAU/HO procedures MME/S4-SGSN GTPv2 entities send some of the RANAP/SIAP/BSSGP 

parameters to a GTPv2 peer. Copying of the BSSGP parameters into GTPv2 IBs is straightforward. RANAP and SlAP, 
however, use ASN.l/PER encoding, which is different from GTPv2 specific TLV encoding. 

Transparent copying of RANAP/SIAP parameters across GTPv2 interfaces: 

a GTPv2 entity shall transparently copy the respective information into one or more octets of the GTPv2 IE as 
specified in Annex X and clause 8.48. With this approach, GTPv2 will not be impacted if the contents of such 
RANAP/SIAP parameter changes over the time. 

Non-transparent copying of RANAP/SIAP parameters across GTPv2 interfaces: 

- GTPv2 entity decodes ASN.l/PER parameter and shall encode the value(s) into one or more octets of the GTPv2 
IE according to what is specified in the present document. 



8.3 International Mobile Subscriber Identity (IMSI) 

International Mobile Subscriber Identity (IMSI) is transferred via GTP turmels. The sending entity copies the value part 
of the IMSI into the Value field of the IMSI IE. IMSI is defined in 3GPP TS 23.003 [2]. 



Bits 

Octets 8 7 6 5 4 3 2 1 



1 


Type = 1 (decimal) 


2 to 3 


Length = n 


4 


Spare 


Instance 


5 


Number digit 2 


Number digit 1 


6 


Number digit 4 


Number digit 3 








n+4 


Number digit m 


Number digit m-1 



Figure 8.3-1 : IMSI 



Octets 5 to (n+4) represent the IMSI value in international number format as described in ITU-T Rec E.164 [25], 
encoded as TBCD digits, i.e. digits from through 9 are encoded "0000" to "1001". When there is an odd number of 
digits, bits 8 to 5 of the last octet are encoded with the filler "1111". The maximum number of digits is 15. 



8.4 Cause 

Cause IE is coded as depicted in Figure 8.4-1. 
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Bits 




8 


7 6 5 4 3 2 1 


1 


Type = 2 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Cause value 




6 


Spare | PCE | BCE | CS 




a(n+1) 


Type of the offending IE 




a(n+2) to 
a(n+3) 


Length of the offending IE = 




a(n+4) 


Spare Instance 





Figure 8.4-1 : Cause 



Cause is a variable length IE, which may have either of the following two lengths values: 

- If n = 2, a = and the Cause IE shall be 6 octets long. Therefore, octets "a(n+l) to a(n+4)" wiU not be present. 

- If n = 6, a = 1 and the Cause IE wiU be 10 octets long. 

For PMIP based S5/S8, the SGW/MAG shall do the mapping between GTPv2 Cause IE and respective PMIPv6 IE as 
specified in 3GPP TS 29.275 [26]. 

The following bits within Octet 6 indicate: 

- Bits 8 to 4: Spare, for future use and set to zero 

- Bit 1 - CS (Cause Source): If this bit is set to 1, it indicates that the corresponding error cause is originated by 
the remote node (i.e., the MME/SGSN to a PGW, or the PGW to an MME/SGSN). This bit is set to to denote 
that the corresponding error cause is originated by the node sending the message. 

The CS should be set to 1 by the SGW when the SGW relay a response message with cause value from the 
MME/SGSN to the PGW or from the PGW to the MME/SGSN. For PMIP based S5/S8, the SGW shall set the 
CS bit to 1 when the SGW/MAG relay a response message with the cause value from the PGW/LMA to the 

MME/SGSN. 

- Bit 2 - BCE (Bearer Context IE Error): If this bit is set to 1, it indicates that the corresponding rejection cause is 
due to the error in the Bearer Context IE. This bit shall be discarded if the cause value is one of Acceptance 
cause value as given in table 8.4-1. 

Bit 3 - PCE (PDN Connection IE Error): If this bit is set to 1, it indicates that the corresponding rejection cause 
is due to the error in the PDN Connection IE. This bit shall be discarded if the cause value is one of Acceptance 
cause value as given in table 8.4-1. 

The Cause value shall be included in a response message. In a response message, the Cause value indicates the 
acceptance or the rejection of the corresponding request message. The Cause value indicates the explicit reason for the 
rejection. 

If the rejection is due to a mandatory IE or a verifiable conditional IE is faulty or missing, the offending IE shall be 
included within an additional field "a(n+l) to a(n+4)". Only Type and Instance fields of the offending IE that caused the 
rejection have a meaning. The length in the Octet 8-9 and spare bits in the Octet 10 shall be set to "0". In this case, the 
value of "n" shall be "6". Otherwise, the value of "n" is equal to "2". 

The Cause may also be included in the request message. In a request message, the Cause value indicates the reason for 
the request. 

"Request accepted" is returned when the GTPv2 entity has accepted a control plane request. 

"Context Not Found" is used in the response message by a GTP entity when it receives a message for which it does not 
have context, e.g. TEID-C or EBI is not known. 

"Context Not Found" may also be used by the PGW during UE requested PDN connectivity procedure while non-3GPP 
to 3GPP handover, if the request corresponds to the handover of the PDN coimection which does not exist with the 
PGW. 

"Service not supported" is used by the GTP entity when it receives a message, which corresponds to a feature or a 
service which is not supported by the node. 
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"Service denied" is used when the requested service cannot be granted. 
"System failure" is used by the GTP entity to indicate a generic error condition. 

"No resources available" is used by the GTP entity to indicate the temporary imavailabihty of the resource(s) to process 
the received request. 

"Semantic error in the TFT operation", "Syntactic error in the TFT operation", "Semantic errors in packet filter(s)", 
"Syntactic errors in packet filters(s)", "UE context without TFT already activated", "Semantic error in the TAD 
operation" and "Syntactic error in the TAD operation" are indications of error cases involving TFT(s)/TAD(s) as 
specified in subclause 7.7.11 in this specification. 

"Missing or unknown APN" is used by the PGW when it does not support the Access Point Name, received in Create 

Session Request message. 

"Relocation failure" is used by the target MME/S4-SGSN to indicate the source MME/S4-SGSN that the relocation has 
failed. 

"Denied in RAT" is used by the GTP entity to indicate that the requested service is not accepted in the RAT. 

"Preferred PDN type not supported" is used by the PGW to indicate that the PDN type received in the Create Session 
Request message is not supported by the PGW for the PDN corresponding to the received Access Point Name. 

"Protocol type not supported" is used by the SGW to indicate that the S5/S8 protocol type requested by the MME/S4- 
SGSN is not supported by it. 

"UE not responding" is used by the MME/S4-SGSN to indicate that the UE is not responding to the request initiated by 
the network, e.g. Paging. 

"UE refuses" is used by the GTP entity to indicate that the UE, without specifying further detail, rejected the request 
from the network. 

"Unable to page UE" is used by the MME/S4-SGSN to indicate its inability to page the UE, temporarily. 

"User authentication failed" is used by the GTP entity to indicate that the request is rejected due to failure in 

authentication/security procedure. 

"APN access denied - no subscription" is used to indicate that the PGW has denied the user access to an APN because a 
subscription is required, but the subscriber does not have the necessary subscription. 

"Remote peer not responding" is used by the SGW for the messages spanning through two interfaces. This cause value 
is returned by the SGW to the MME/S4-SGSN or PGW in a response message where no response message is received 
from the PGW or MME/S4-SGSN. 

"Collision with network initiated request" is used by the PGW to indicate that the UE-initiated bearer resource 
allocation/modification request is rejected since the PGW has requested a bearer resource allocation/modification for 
the same service using a network-initiated procedure. 

"Unable to page UE due to Suspension" is used by the MME/S4-SGSN to indicate that the UE has not been paged 
because the bearers of the UE are in a suspended state. 

"APN Restriction type Incompatible with currently active PDN connection" is used by the PGW to indicate that the 
newly requested PDN connection has APN restriction value that is not compatible with the currently active PDN 
connection(s)'s APN restriction value(s). 

"Invalid peer" is used by the SGW to indicate that currently the UE is being managed by the different node (e.g. 
MME/S4-SGSN) than the node (e.g. S4-SGSN/MME) which has sent the Delete Session Request message. 

"Invalid Reply from remote peer" is used by the SGW for the messages spanning through two interfaces. This cause 
value is returned by the SGW to the MME/SGSN or PGW in a reply message where the corresponding reply message 
on S5/S8 or SI 1/S4 from the PGW or MME/SGSN is not decoded as valid. 

"Temporarily rejected due to handover procedure in progress" is used by the MME for the bearer related procedure 
initiated by the PGW. When the X2 based handover with/without SGW change or SI based handover with/without 

SGW and/or MME change is in progress, the MME may receive Create / Update / Delete Bearer request message for 
the bearer creation, modification or deletion initiated by the PGW. If the handover procedure results in the SGW and/or 
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MME change, then the bearer related procedure cannot be handled temporarily by the MME till the handover procedure 
is completed. In that case the MME shall reject the bearer related procedure with this rejection cause. 

The usage of "Fallback to GTPvl" is specified in subclause 7.10 "Fallback to GTPvl mechanism". 

In the PGW initiated PDN connection deactivation procedure, the PGW may include the Cause IE in the Delete 
Bearer Request with values "RAT changed from 3GPP to Non-3GPP", "Reactivation requested" or 
"Reactivation disallowed to APN". 

"APN Congestion" is used by the PGW and it indicates that the PGW has detected congestion for the requested APN 
and performs overload control for that APN which does not allow the PDN connection to be established. 

"UE already re-attached" is used by MME/S4-SGSN for the network triggered service restoration procedure as 
specified in 3GPP TS 23.007 [17]. The MME/S4-SGSN may send the Downlink Data Notification Acknowledge or 
Downlink Data Notification Failure Indication with this cause as part of the network triggered service restoration 
procedure. 

"PDP connection inactivity timer expires" is used by the PGW in Delete Bearer Request(s) to indicate that all the 
bearer(s) for the emergency PDN connection are deleted upon the inactivity timer expiry as specified in 3GPP TS 
23.203 [48]. 

"Network failure" is used by the SGSN or MME in the Delete Session Request to indicate that the message is sent due 
to a network problem. 

"QoS parameter mismatch" is used by the SGSN or MME in the Delete Session Request to indicate that the PDN 
connection can not be established due to a QoS parameter mismatch. 

The listed cause values for rejection response message descriptions in clause 7 are not meant to be exhaustive lists. 
Therefore a GTPv2 node shall use the most appropriate matching rejection response cause value that is listed in Table 
8.4-1. 

If a Bearer Resource Command message is related to an established PDN connection for LIP A, the LGW shall reject 
the Bearer Resource Command with the cause value of "Bearer handling not supported". 

"Multiple PDN connections for a given APN not allowed" is used by SGW for reply message to the MME/S4-SGSN 
when PMIP -based S5/S8 is used. If either SGW or PGW does not support the multiple PDN connections to the same 
APN function, the SGW shall reject the PDN connectivity request procedure with this rejection cause when receiving 
Create Session Request for additional PDN connectivity to the given APN from the same UE. 

As specified in sub-clause 5.3.1.1 in 3GPP TS 23.401 [3] and sub-clause 9.2.1 in 3GPP TS 23.060 [35], the cause value 
"New PDN type due to network preference" indicates that the UE has requested PDN type IPv4v6 and only IPv4 or 
IPv6 address is allowed for the PDN based on PGW operator policy. 

As specified in sub-clause 5.3.1.1 in 3GPP TS 23.401 [3] and sub-clause 9.2.1 in 3GPP TS 23.060 [35], the cause value 
"New PDN type due to single address bearer only" indicates that the MS has requested PDN type IPv4v6 and both IPv4 

and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag of the Indication IE is set to or the 
Indication IE is absent, or only single IP version addressing is possible in the PDN. 

"PGW not responding" is used by the SGW in PGW Restart Notification to indicate that the peer PGW has failed and 
not restarted as specified in subclause 7.9.5. 

"UE context without TFT already activated" is used by the PGW in the Bearer Resource Failure Indication message to 
indicate that the PGW has received the Bearer Resource Command message without TAD IE in the secondary PDP 
Context Activation procedure. 
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Table 8.4-1 : Cause values 





VyaUoC ValUc 
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93 


APN poopQc; Hpnipri — nn ^uh^^rrintion 




94 


Request rejected (reason not specified) 




95 


P-TIVISI Signature mismatch 




96 


IMSI/IMEI not known 




97 


Semantic error in the TAD operation 




98 


Syntactic error in the TAD operation 




99 


Shali not be used. See NOTE 2 and NOTE 3. 




100 


Remote peer not responding 




101 


Collision with network initiated request 
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1 ud 


Unable to page UE due to Suspension 


H no 


Conditional IE missing 


1 U4 


APN Restriction type Incompatible with currently active PDN connection 


105 


Invalid overall length of the triggered response message and a piggybacked initial 
message 


\ Uo 


Data forwarding not supported 


^ nv 
1 U / 


Invalid reply from remote peer 


1 Uo 


raiiuacK to La 1 rV 1 


1 uy 


Invalid peer 


1 1 U 


1 emporariiy rejecieo oue lo nanoover proceaure in progress 


i i i 

111 


Modifications not limited to 31 -U bearers 


112 


Request rejected for a PMIPv6 reason (see 3GPP TS 29.275 [26]). 


1 1 


APN Congestion 


114 


Bearer handling not supported 


115 


UE already re-attached. See NOTE 7. 


116 


Multiple PDN connections for a given APN not allowed 


117 to 239 


Spare. For future use in a triggered/response message See NOTE 4. 


Request / Initial 
message 


240 to 255 


Spare. For future use in an initial/request message. See NOTE 5. 


NOTE 1 : The listed cause values for rejection in a response/triggered message can be also used for request 

messages if the request message is triggered by a command message. 
NOTE 2: Subclause 7.7.8 "Semantically incorrect Information Element" specifies quite strict handling of the reserved 

values and therefore this table shall not contain any reserved values. 
NOTE 3: This value was used in earlier versions of the spec. If received, it shall be interpreted as unspecified 

rejection cause. Unspecified/unrecognized rejection cause shall be treated in the same ways as the cause 

value 94 "Request rejected (reason not specified)". 
NOTE 4: This value is or may be used in the newer versions of the spec. If the receiver cannot comprehend the 

value, it shall be interpreted as unspecified rejection cause. Unspecified/unrecognized rejection cause shall 

be treated in the same ways as the cause value 94 "Request rejected (reason not specified)". 
NOTE 5: This value is or may be used in the newer versions of the spec. If the receiver cannot comprehend the 

value, it shall be interpreted as an unspecified request/initial message cause. Unspecified/unrecognized 

cause handling in a request/initial message shall be implementation dependent (e.g. may be ignored). 
NOTE 6: This Cause value is only used over the S4 interface. 

NOTE 7: This cause value may also be used by a Downlink Data Notification Failure Indication, which is an initial 
message. 



The mapping at the MME/S4-SGSN between GTP cause values received over the SI 1/S4 interface and the NAS cause 
values sent to the UE is specified in Annex C. 

8.5 Recovery (Restart Counter) 

Recovery IE is coded as depicted in Figure 8.5-1. 

In the first release of GTPv2 spec n = I. That is, the overall length of the IE is 5 octets. In future releases of the spec 
additional octets may be specified. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 3 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Recovery (Restart Counter) 





Figure 8.5-1 : Recovery (Restart Counter) 



8.6 Access Point Name (APN) 

Access Point Name (APN) is transferred via GTP tunnels. The sending entity copies the value part of the APN into the 
Value field of the APN IE. 
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Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 71 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Access Point Name (APN) 





Figure 8.6-1 : Access Point Name (APN) 



The encoding the APN field follows 3GPP TS 23.003 |2J subclause 9.1. The content of the APN field shall be the full 
APN with both the APN Network Identifier and APN Operator Identifier being present as specified in 3GPP TS 23.003 
[2] subclauses 9.1.1 and 9.1.2, 3GPP TS 23.060 [35] Annex A and 3GPP TS 23.401 |3| subclauses 4.3.8.1. 

NOTE: The APN field is not encoded as a dotted string as commonly used in documentation. 

8.7 Aggregate Maximum Bit Rate (AlVIBR) 

Aggregate Maximum Bit Rate (AMBR) is transferred via GTP tunnels. The sending entity copies the value part of the 
AMBR into the Value field of the AMBR (APN- AMBR) IE. 

AMBR is defined in clause 9.9.4.2 of 3GPP TS 24.301 [23], but shall be formatted as shown in Figure 8.7-1 as 
Unsigned32 binary integer values in kbps (1000 bits per second). 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 72 (decimal) 




2 to 3 


Length = 8 




4 


Spare Instance 




5 to 8 


APN-AMBR for uplink 




9 to 12 


APN-AMBR for downlink 





Figure 8.7-1 : Aggregate lUlaximum Bit Rate (AlUlBR) 



8.8 EPS Bearer ID (EBI) 

EPS Bearer ID (EBI) is coded as depicted in Figure 8.8-1. 

The overall length of the IE is 5 octets. In future releases of the spec additional octets may be specified and new 
semantic for the spare bits may be defined. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 73 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare (all bits set to 0) 


EPS Bearer ID (EBI) 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.8-1 : EPS Bearer ID (EBI) 



The coding of EBI field and its value range is specified in 3GPP TS 24.007 [30], subclause 11.2.3.1.5, bits 5 to 8. 

8.9 IP Address 

IP Address is coded as depicted in Figure 8.9-1. The Length field may have only two values (4 or 16) that determine if 
the Value field contains IPv4 or IPv6 address. 
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Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 74 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


IPv4 or IPv6 Address 





Figure 8.9-1 : IP address 



8.10 Mobile Equipment Identity (MEI) 

Mobile Equipment Identity (MEI) is coded as depicted in Figure 8.10-1.. MEI is defined in clause 6.2 of 3GPP TS 
23.003 [2]. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 75 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Mobile Equipment (ME) Identity 





Figure 8.10-1 : lUlobile Equipment (lUlE) Identity (lUIEI) 



The ME Identity field contains either the IMEI or the IMEISV as defined in clause 6.2 of 3GPP TS 23.003 [2]. It is 
encoded as specified in clause 7.7.53 of 3GPP TS 29.060 [4], beginning with octet 4 of Figure 7.7.53.1. 

The IMEI(SV) digits are encoded using BCD coding where IMEI is 15 BCD digits and IMEISV is 16 BCD digits. For 
IMEI, bits 5 to 8 of the last octet shall be filled with an end mark coded as '1 1 11'. 

8.11 MSISDN 

MSISDN is transferred via GTP tunnels. The sending entity copies the value part of the MSISDN into the Value field of 
the MSISDN IE. MSISDN is defined in 3GPP TS 23.003 [2]. 



Bits 

Octets 8 7 6 5 4 3 2 1 



1 


Type = 76 (decimal) 


2 to 3 


Length = n 


4 


Spare 


Instance 


5 


Number digit 2 


Number digit 1 


6 


Number digit 4 


Number digit 3 








n+4 


Number digit m 


Number digit m-1 



Figure 8.11-1: MSISDN 



Octets 5 to (n+4) represent the MSISDN value is in international number format as described in ITU-T Rec E.164 [25] 
and 3GPP TS 29.002 [41]. MSISDN value contains only the actual MSISDN number (does not contain the "nature of 
address indicator" octet, which indicates "international number" as in 3GPP TS 29.002 [41]) and is encoded as TBCD 
digits, i.e. digits from through 9 are encoded "0000" to " 1001". When there is an odd number of digits, bits 8 to 5 of 
the last octet are encoded with the filler "1111". 



8.12 Indication 

Indication is coded as depicted in Figiu-e 8.12-1. 
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ucieis 


8 


7 


6 


Bits 
5 4 


3 


2 


1 


1 


Type = 77 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


DAF 


DTP 


HI 


DFI 


01 


ISRSI 


ISRAI 


SGW 
CI 




6 


SQCI 


UIMSI 


CFSI 


CRSI 


P 


PI 


SI 


IVISV 




7 


RetLo 
c 


PBIC 


SRNI 


S6AF 


S4AF 


MBM 
DT 


ISRA 
U 


CCRS 
1 




8 


Spare 


Spare 


Spare 


Spare 


Spare 


Spare 


CLII 


CPSR 




9 to (n+4) 


These octet(s) is/are present only If explicitly specified 





Figure 8.12-1: Indication 



For each message the applicable flags of the Indication IE shall be clearly specified in the individual message sub 
clause. The remaining flags of the Indication IE not so indicated shall be discarded by the receiver. 

The receiver shall consider the value of the applicable flags as "0", if the Indication IE is applicable for the message but 
not included in the message by the sender. 

The following bits within Octet 5 shall indicate: 

- Bit 8 - DAF (Dual Address Bearer Flag): This bit shall be set when the PDN Type, determined based on UE 
request and subscription record, is set to IPv4v6 and all SGSNs which the UE may be handed over to are 
Release 8 or above supporting dual addressing, which is determined based on node pre-conflguration by the 
operator.. 

- Bit 7 - DTF (Direct Tunnel Flag): This bit shall be set when the UE is in UTRAN/GERAN network and Direct 
Timnel is selected 

- Bit 6 - HI (Handover Indication): If this bit is set to 1 over SI 1/S4 and S5/S8 interfaces, it shall indicate that a 
UE handover from a non-3GPP access to a 3GPP access system. This bit is applicable during the E-UTRAN 
Initial Attach procedure, PDP Context Activation procedure or during the UE requested PDN connectivity 
procedure. If this bit is set to 1 over GTP based S2b interface, it shall indicate the UE handover to Untrusted 
Non-3GPP Access system and IP address preservation is requested by the UE. 

Bit 5 - DFI (Direct Forwarding Indication): If this bit is set to 1, it shall indicate that the direct forwarding 
between the source eNodeB and the target eNodeB during the SI based handover procedure is apphed. 

- Bit 4 - OI (Operation Indication): 

If this bit is set to 1, it shall denote that the receiving SGW of a "Create Session Request" shall send a Modify 
Bearer Request immediately to the PGW. This allows the SGW to differentiate if the "Create Session 
Request" received on S4/S1 1 interface belongs to a TAU/RAU with an SGW relocation (OI = 1), or X2- 
based handover with SGW relocation (OI = 1) or SI -based handover with SGW relocation (OI = 0). 

- It shall be set to 1 on S4/S1 1 interface if the SGW needs to forward the Delete Session Request message to 
PGW. 

- Bit 3 - ISRSI (Idle mode Signalhng Reduction Supported Indication): If this is set to 1, it shall indicate that the 
old/source SGSN/MME and the associated SGW are capable to activate ISR. 

Bit 2 - ISRAI (Idle mode Signalling Reduction Activation Indication): If this bit is set to 1, it shall indicate that 
the ISR is established between the MME and the S4 SGSN during a TAU/RAU without an SGW change 
procedure or during an Inter RAT handover without an SGW change procedure. The SGW shall retain the 
resources for the other CN node that has its bearer resources on the SGW reserved. The old/source SGSN/MME 
shall maintain the UE's contexts and activate ISR. 

- Bit 1 - SGWCI (SGW Change Indication): If this bit is set to 1, it shall indicate that the target MME/SGSN has 
selected a new SGW during a TAU/RAU or handover with an SGW change procedure. 

The following bits within Octet 6 shall indicate: 

Bit 8 - SQCI (Subscribed QoS Change Indication): If this bit is set to 1, it indicates that the subscribed QoS 
profile of the related PDN connection has changed in the old MME/SGSN when the UE is in ECM-IDLE state 
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and ISR is activated. The new MME/SGSN shall trigger the Subscribed QoS Modification procedure. See 3GPP 

TS 23.401 [3], clause 5.3.9.2. 

- Bit 7 - UIMSI (Unauthenticated IMSI): If this bit is set to 1, it indicates that the IMSl present in the message is 
not authenticated and is for emergency attached UE. 

- Bit 6 - CFSI (Change F-TEID support indication): if this bit is set to 1, it indicates that the SGW can change the 
assigned GTP-U F-TEID in the current procedure. If the SGW needs to modify the GTP-U F-TEID and the CFSI 
flag is set to 1 in the corresponding request message, the SGW shall include the new F-TEID in the Modify 
Bearer Response/Modify Access Bearers Response message. 

- Bit 5 - CRSI (Change Reporting support indication): if this bit is set to 1, it indicates that the MME/S4 SGSN 
supports Location Change Reporting mechanism for the corresponding session. 

- Bit 4 - PS (Piggybacking Supported). This bit denotes whether the MME/SGW support piggybacking feature as 
described in Annex F of 3GPP TS 23.401 [3]. If set to 1, it indicates that the node is capable of processing two 
different GTP-C messages appearing back to back in a single UDP payload. 

- Bit 3 - PT (Protocol Type) If this bit set to 1, it shall indicate that the protocol type for the S5/S8 interface is 
PMIP; this bit is set to to indicate that the protocol type for the S5/S8 interface is GTP. 

Bit 2 - SI (Scope Indication): If this bit is set to 1, it indicates that all bearer resources of the UE shall be 
released by the SGW. This flag is set in messages during TAU/RAU/Handover with SGW change /SRNS 
Relocation Cancel Using S4 with SGW change/Inter RAT handover Cancel procedure with SGW change/S 1 
Based handover Cancel procedure with SGW change. 

- Bit 1 - MSV (MS Vahdated): If this bit is set to 1, it shall indicate that the new MME/SGSN has successfully 
authenticated the UE. 

The following bits within Octet 7 shall indicate: 

- Bit 8 - RetLoc (Retrieve Location Indication Flag): if this bit is set to 1, it indicates that the PGW requests the 
MME/SGSN to provide the User Location Information. 

Bit 7 - PBIC (Propagate BBAI Information Change): if this bit is set to 1, it indicates a change in the H(e)NB 

local IP address and/or UDP port number, i.e. the UE moves from an (e)NB to a H(e)NB, or from one H(e)NB to 
another H(e)NB with the fixed network backhaul changed, or the UE moves from a H(e)NB to a (e)NB. 

- Bit 6 - SRNI (SGW Restoration Needed Indication): if this bit is set to 1, it indicates that the source MME/S4- 
SGSN has not performed the SGW relocation procedure after the source SGW has failed with or without restart, 
when the source and target MME/S4-SGSN support the MME/S4-SGSN triggered SGW restoration procedure as 
specified in 3GPP TS 23.007 [17]. 

- Bit 5 - S6AF (Static IPv6 Address Flag): if this bit is set to 1, it indicates that PDP/PDN IPv6 address is static. 

- Bit 4 - S4AF (Static IPv4 Address Flag): if this bit is set to 1, it indicates that PDP/PDN IPv4 address is static. 

- Bit 3 - MBMDT (Management Based MDT allowed flag): if this bit is set to 1, it indicates that management 
based MDT is allowed. 

- Bit 2 - ISRAU (ISR is activated for the UE): if this bit is set to 1, it indicates that ISR is activated for the UE 
before the UE moving to the new SGSN/MME. 

- Bit 1 - CCRSl (CSG Change Reporting support indication): if this bit is set to 1, it indicates that the MME/S4 
SGSN supports CSG Information Change Reporting mechanism for the corresponding session. 

The following bits within Octet 8 shall indicate: 

Bit 8 to 3 - Spare, for future use and set to zero. 

- Bit 2 - CLll (Change of Location Information Indication): when ISR is active if this bit is set to 1, it indicates 
that the location information, which is provided as a part of ULI IE, has changed since last reported by the 
MME/S4-SGSN. The SGW shall ignore this flag when ISR is not active. 
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- Bit 1 - CPSR (CS to PS SRVCC indication): if this bit is set to 1, it indicates that a UTRAN/GERAN to E- 
UTRAN/UTRAN (HSPA) SRVCC procedure is underway and the associated message, i.e. Modify Bearer 
Request shall be forwarded to the PGW from the SOW as specified in 3GPP TS 23.216 [43]. 

8.13 Protocol Configuration Options (PCO) 

Protocol Configuration Options (PCO) is transferred via GTP tunnels. The sending entity copies the value part of the 
PCO into the Value field of the PCO IE. The detailed coding and maximum length of the PCO field from octets 5 to 
(n+4) shall be specified as per clause 10.5.6.3 of 3GPP TS 24.008 [5], starting with octet 3. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 78 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Protocol Configuration Options (PCO) 





Figure 8.13-1: Protocol Configuration Options (PCO) 



8.14 PDN Address Allocation (PAA) 

The PDN Address Allocation is coded as depicted in Figure 8.14-1. 
NOTE: The Prefix Length within PAA IE has a fixed value of /64. 







Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 79 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare | PDN Type 




6 to (n+4) 


PDN Address and Prefix 





Figure 8.14-1: PDN Address Allocation (PAA) 
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Table 8.14-1 : PDN Address Allocation 



PDN type value (octet 5) 



Bits 






3 2 


1 







1 


IPv4 


1 





IPv6 


1 


1 


IPv4v6 



All other values are reserved. 

Bits 8-4 of octet 5 are spare and shall be coded as zero. 

PDN Address and Prefix (octet 6 to n+4) 

If PDN type value indicates IPv4, an IPv4 address is present in the PDN Address and 
Prefix from octet 6 to octet 9. Bit 8 of octet 6 represents the most significant bit of the 
IPv4 address and bit 1 of octet 9 the least significant bit. 

If PDN type value indicates IPv6, octet 6 contains the IPv6 Prefix Length. Octets 7 
through 22 contain an IPv6 Prefix and Interface Identifier. Bit 8 of octet 7 represents 
the most significant bit of the IPv6 Prefix and Interface Identifier and bit 1 of octet 22 

the least significant bit. 

If PDN type value indicates IPv4v6, octet 6 contains the IPv6 Prefix Length. Octets 7 
through 22 contain an IPv6 Prefix and Interface Identifier. Bit 8 of octet 7 represents 
the most significant bit of the IPv6 Prefix and Interface Identifier and bit 1 of octet 22 
the least significant bit. Octets 23 through 26 contain an IPv4 address. Bit 8 of octet 23 
represents the most significant bit of the IPv4 address and bit 1 of octet 26 the least 
significant bit. 



8. 1 5 Bearer Quality of Service (Bearer QoS) 

Bearer Quality of Service (Bearer QoS) is transferred via GTP tunnels. The sending entity copies the value part of the 
Bearer 1 QoS into the Value field of the Bearer QoS IE. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 80 (decimal) 




2-3 


Length = n 




4 


Spare Instance 




5 


Spare 1 PCI | PL | Spare | PVI 




6 


Label (QCI) 




7 to 11 


Maximum bit rate for uplink 




12to 16 


IVIaximum bit rate for downlink 




17 to 21 


Guaranteed bit rate for uplink 




22 to 26 


Guaranteed bit rate for downlink 




27 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.15-1 : Bearer Level Quality of Service (Bearer QoS) 



Octet 5 represents the Allocation/Retention Priority (ARP) parameter. The meaning and value range of the parameters 
within the ARP are defined in 3GPP TS 29.212 [29]. The bits within the ARP octet are: 

- Bit 1 - PVI (Pre-emption Vulnerability): See 3GPP TS 29.212[29], clause 5.3.47 Pre-emption- Vulnerability 
AVP. 

- Bit 2 - spare 

- Bits 3 to 6 - PL (Priority Level): See 3GPP TS 29.212[29], clause 5.3.45 ARP- Value AVP. PL encodes each 
priority level defined for the ARP- Value AVP as the binary value of the priority level. 

- Bit 7 - PCI (Pre-emption CapabiUty): See 3GPP TS 29.212[29], clause 5.3.46 Pre-emption-Capabihty AVP. 



ETSI 



3GPP TS 29.274 version 11.5.0 Release 11 



159 



ETSI TS 129 274 V1 1.5.0 (2013-01) 



- Bit 8 - spare. 

Octet 6 contains the "QCI" value, as specified in 3GPP TS 23.203 [48]. 

The UL/DL MBR and GBR fields are encoded as kilobits per second (1 kbps = 1000 bps) in binary value. For non-GBR 
bearers, both the UL/DL MBR and GBR should be set to zero. The range of QCI, Maximum bit rate for uphnk. 
Maximum bit rate for downhnk. Guaranteed bit rate for uphnk and Guaranteed bit rate for downlink are specified in 
3GPPTS 36.413 [10]. 

NOTE: The encoding in 3GPP TS 24.301 [23] and 3GPP TS 36.413 [10] is different from the encoding within 
this specification. 

8. 1 6 Flow Quality of Service (Flow QoS) 

Flow Quality of Service (Flow QoS) is transferred via GTP tunnels. The sending entity copies the value part of the Flow 
QoS into the Value field of the Flow QoS IE. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 81 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Label (QCI) 




6 to 10 


Maximum bit rate for uplink 




11 to 15 


Maximum bit rate for downlinl< 




16 to 20 


Guaranteed bit rate for uplinl< 




21 to 25 


Guaranteed bit rate for downlinl^ 




26 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.16-1 : Flow Quality of Service (Flow QoS) 



Octet 5 contains the "QCI" value, as specified in 3GPP TS 23.203 [48]. 

The UL/DL MBR and GBR fields are encoded as kilobits per second (1 kbps = 1000 bps) in binary value. For non-GBR 

bearers, both the UL/DL MBR and GBR should be set to zero. The range of QCI, Maximum bit rate for uplink. 
Maximum bit rate for downlink. Guaranteed bit rate for uplink and Guaranteed bit rate for downlink are specified in 
3GPPTS 36.413 [10]. 

NOTE: The encoding in 3GPP TS 24.301 [23] and 3GPP TS 36.413 [10] is different from the encoding within 
this specification. 

8.17 RAT Type 

RAT Type is coded as depicted in Figure 8.17-1. 



Octets 


8 


Bits 

7 6 5 4 3 2 1 


1 


Type = 82 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


RAT Type 




6 to (n+4) 


These octet(s) is/are present only If explicitly specified 





Figure 8.17-1 : RAT Type 
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Table 8.17-1 : RAT Type values 



RAT TunA^ 


VflliiPQ ^Dppimfil^ 


<reserved> 





UTRAN 


1 


GERAN 


2 


WLAN 


3 


GAN 


4 


HSPA Evolution 


5 


EUTRAN 


6 


Virtual 


7 


<spare> 


8-255 



NOTE 1: For S4-SGSN, currently it is only possible to detect the difference between GERAN and UTRAN when 
GERAN Gb mode is used. If GERAN lu mode is used, then an S4-SGSN may not be able to detect the 
difference between GERAN and UTRAN. Across the Gb interface, the SGSN may also not be able to 
detect the difference between GERAN and GAN. If S4-SGSN cannot detect that the HSPA Evolution 
3GPP TR 25.999 [46] network is behind the lu interface, the S4-SGSN will send the "UTRAN" RAT 
Type. 

NOTE 2: For the lu interface case, if the SGSN detects UTRAN or HSPA, it sets the RAT-Type to "UTRAN". If 
the SGSN detects HSPA+, it sets the RAT-Type to "HSPA Evolution", otherwise the SGSN will send the 
"UTRAN" RAT Type. 

8.18 Serving Network 

Serving Network is coded as depicted in Figure 8.18-1. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 83 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


IVIGC digit 2 


IVIGG digit 1 




6 


IVING digit 3 


IVIGG digit 3 




7 


l\/lNCdigit2 


IVINC digit 1 




8 to (n+4) 


These octet(s) is/are present only If explicitly specified 





Figure 8.18-1 : Serving Network 



If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as " 11 11 " . 
This IE contains the serving network provided by the MME, S4-SGSN or ePDG. 

8.1 9 EPS Bearer Level Traffic Flow Template (Bearer TFT) 

EPS Bearer Level Traffic Flow Template (Bearer TFT) is transferred via GTP tunnels. The sending entity copies the 
value part of the EPS Bearer Level TFT into the Value field of the EPS Bearer Level TFT IE. The detailed coding and 
maximum length of the EPS Bearer Level TFT IE is specified in 3GPP TS 24.008 [5], clause 10.5.6.12, beginning with 
octet 3. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 84 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


EPS Bearer Level Traffic Flow Template (TFT) 





Figure 8.19-1 : EPS Bearer Level Traffic Flow Template (Bearer TFT) 
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8.20 Traffic Aggregate Description (TAD) 

The Traffic Aggregate Description IE is coded as depicted in Figure 8.20-1. The detailed coding and maximum length 
of Traffic Aggregate Description is specified in 3GPP TS 24.008 [5], clause 10.5.6.12, beginning with octet 3.. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 85 (Decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Traffic Aggregate Description 





Figure 8.20-1 Traffic Aggregate Description 



8.21 User Location Information (ULI) 

User Location Information (ULI) is a extendable IE that is coded as depicted in Figure 8.21-1. The CGI, SAJ, RAl, 
TAX, ECGI and LAI identity types are defined in 3GPP TS 23.003 [2]. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 86 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare | LAI | ECGI 


TAI 1 RAl 1 SAI 1 CGI 




a to a+6 


CGI 




b to b+6 


SAI 




c to c+6 


RAl 




d to d+4 


TAI 




e to e+6 


ECGI 




f to f+4 


LAI 




g to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.21-1: User Location Information 



The ULI IE shall contain only one identity of the same type (e.g. more than one CGI cannot be included), but ULI IE 
may contain more than one identity of a different type (e.g. ECGI and TAI). The flags LAI, ECGI, TAI, RAl, SAI and 
CGI in octet 5 indicate if the corresponding type shall be present in a respective field or not. If one of these flags is set 
to "0", the corresponding field shall not be present at all. If more than one identity of different type is present, then they 
shall be sorted in the following order: CGI, SAI, RAl, TAI, ECGI, LAI. 

The following subclauses specify the coding of the fields representing different identities. 

For each identity, if an Administration decides to include only two digits in the MNC, then "MNC digit 3" field of 
corresponding location shall be coded as "1111". 

8.21.1 CGI field 

The coding of CGI (Cell Global Identifier) is depicted in Figure 8.21.1-1. Only zero or one CGI field shall be present in 
ULI IE. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


a 


MCC digit 2 


MCC digit 1 




a+1 


MNC digit 3 


MCC digit 3 




a+2 


MNC digit 2 


MNC digit 1 




a+3 to a+4 


Location Area Code (LAC) 




a+5 to a+6 


Cell Identity (CI) 





Figure 8.21.1-1: CGI field 
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The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet a+3 is the most significant bit and bit 1 of Octet a+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
fuU hexadecimal representation shall be used. 

The Cell Identity (CI) consists of 2 octets. Bit 8 of Octet a+5 is the most significant bit and bit 1 of Octet a+6 the least 
significant bit. The coding of the cell identity is the responsibility of each administration. Coding using fuU hexadecimal 
representation shall be used. 

8.21.2 SAI field 

The coding of SAI (Service Area Identifier) is depicted in Figure 8.21.2-1. Only zero or one SAI field shall be present 
in ULI IE. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


b 


MCC digit 2 


MCC digit 1 




b+1 


MNC digit 3 


IVICC digit 3 




b+2 


MNC digit 2 


IVINC digit 1 




b+3 to b+4 


Location Area Code (LAC) 




b+5 to b+6 


Service Area Code (SAC) 





Figure 8.21 .2-1: SAI field 



The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet b+3 is the most significant bit and bit 1 of Octet b+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

The Service Area Code (SAC) consists of 2 octets. Bit 8 of Octet b+5 is the most significant bit and bit 1 of Octet b+6 
the least significant bit. The SAC is defined by the operator. See 3GPP TS 23.003 [2] section 12.5 for more information. 

8.21.3 RAI field 

The coding of RAI (Routing Area Identity) is depicted in Figure 8.21.3-1. Only zero or one RAI field shall be present in 
ULI IE. 



Bits 

Octets 8 7 6 5 4 3 2 1 



c 


IVICC digit 2 


MCC digit 1 


c+1 


MNC digit 3 


MCC digit 3 


c+2 


MNC digit 2 


MNC digit 1 


c+3 to c+4 


Location Area Code (LAC) 


c+5 to c+6 


Routing Area Code (RAC) 



Figure 8.21.3-1: RAI field 



The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet c+3 is the most significant bit and bit 1 of Octet c+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
fuU hexadecimal representation shall be used. 

The Routing Area Code (RAC) consists of 2 octets. Only Octet c+5 contains the RAC. Octet c+6 is coded as all I's 
(1 1 1 1 1 1 1 1). The RAC is defined by the operator. 

8.21.4 TAI field 

The coding of TAI (Tracking Area Identity) is depicted in Figure 8.21.4-1. Only zero or one TAI field shall be present 
in ULI IE. 
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Octets 


Bits 

8 7 6 5 4 3 2 1 


d 


MCC digit 2 


IVICC digit 1 




d+1 


MNC digit 3 


MCC digit 3 




d+2 


MNC digit 2 


MNC digit 1 




d+3 to d+4 


Tracking Area Code (TAG) 





Figure 8.21 .4-1 :TAI 



The Tracking Area Code (TAC) consists of 2 octets. Bit 8 of Octet d+3 is the most significant bit and bit 1 of Octet d+4 
the least significant bit. The coding of the tracking area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

8.21.5 ECGI field 

The coding of ECGI (E-UTRAN Cell Global Identifier) is depicted in Figure 8.21.5-1. Only zero or one ECGI field 
shall be present in ULI IE. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


e 


MCC digit 2 


MCC digit 1 




e+1 


MNC digit 3 


MCC digit 3 




e+2 


MNC digit 2 


MNC digit 1 




e+3 


Spare 


ECl 




e+4 to e+6 


EC! (E-UTRAN Cell Identifier) 





Figure 8.21 .5-1: ECGI field 



The E-UTRAN Cell Identifier (ECI) consists of 28 bits. The ECI field shall start with Bit 4 of octet e+3, which is the 
most significant bit. Bit 1 of Octet e+6 is the least significant bit. The coding of the E-UTRAN cell identifier is the 
responsibiUty of each administration. Coding using full hexadecimal representation shall be used. 

8.21.6 LAI field 

The coding of LAI (Location Area Identifier) is depicted in Figure 8.21.6-1. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


f 


MCC digit 2 


MCC digit 1 




f+1 


MNC digit 3 


MCC digit 3 




f+2 


MNC digit 2 


MNC digit 1 




f+3 to f+4 


Location Area Code (LAC) 





Figure 8.21 .6-1: LAI field 



The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet f+3 is the most significant bit and bit 1 of Octet f+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
fuU hexadecimal representation shall be used. 

8.22 Fully Qualified TEID (F-TEID) 

FuUy QuaUfied Tunnel Endpoint Identifier (F-TEID) is coded as depicted in Figure 8.22-1. 
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Bits 




8 7 6 5 4 3 2 1 


\ 


Type = 87 (decimal) 




^10 O 


Length = n 




4 


Spare Instance 




5 


V4 V6 Interface Type 




6 to 9 


TEID/GRE Key 




m to (m+3) 


IPv4 address 




p to (p+1 5) 


IPv6 address 




k to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.22-1 : Fully Qualified Tunnel Endpoint Identifier (F-TEID) 



The following flags are coded within Octet 5: 

- Bit 8 - V4: If this bit is set to "1", then IPv4 address field exists in the F-TEID, otherwise the IPv4 address field 
is not present at all. 

- Bit 7 - V6: If this bit is set to "1", then IPv6 address field exists in the F-TEID, otherwise the IPv6 address field 
is not present at all. 

At least one of V4 and V6 shall be set to "1", and both may be set to "1". 

- Bit 6 to Bit 1 - Interface Type: This 6 bit wide integer can take the following values representing interface type 
and endpoint: 

0: Sl-U eNodeB GTP-U interface 
1: Sl-U SOW GTP-U interface 
2: S12RNC GTP-U interface 
3: S12SGW GTP-U interface 
4: S5/S8 SGW GTP-U interface 
5: S5/S8 PGW GTP-U interface 
6: S5/S8 SGW GTP-C interface 
7: S5/S8 PGW GTP-C interface 

8: S5/S8 SGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and since alternate CoA is 
not used the control plane and user plane addresses are the same for PMlPv6) 

9: S5/S8 PGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and the control plane and 
user plane addresses are the same for PMIPv6) 

10: Sll MME GTP-C interface 

11 : S 11/S4 SGW GTP-C interface 

12: SIO MME GTP-C interface 

13: S3 MME GTP-C interface 

14: S3 SGSN GTP-C interface 

15: S4 SGSN GTP-U interface 

16: S4 SGW GTP-U interface 

17: S4 SGSN GTP-C interface 

18: S16 SGSN GTP-C interface 
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19: eNodeB GTP-U interface for DL data forwarding 
20: eNodeB GTP-U interface for UL data forwarding 
21: RNC GTP-U interface for data forwarding 
22: SGSN GTP-U interface for data forwarding 
23: SGW GTP-U interface for DL data forwarding 
24: Sm MBMS GW GTP-C interface 
25: Sn MBMS GW GTP-C interface 
26: Sm MME GTP-C interface 
27: Sn SGSN GTP-C interface 
28: SGW GTP-U interface for UL data forwarding 
29: Sn SGSN GTP-U interface 
30: S2b ePDG GTP-C interface 
31: S2b-U ePDG GTP-U interface 
32: S2b PGW GTP-C interface 
33: S2b-U PGW GTP-U interface 
34: S2a TWAN GTP-U interface 
35: S2a TWAN GTP-C interface 
36: S2a PGW GTP-C interface 
37: S2a PGW GTP-U interface 
Other values of "Interface Type" are spare and reserved for future use. 

"Interface type" values with bit "6" set to 1 shall only be used between Rel-10 onwards GTPv2-C nodes. 

NOTE: "Interface type" IE is defined with 5 bits only in the earlier releases of this specification, thus pre-Rel-10 
GTPv2-C nodes can ignore bit "6" which is marked as "Spare" in earUer releases, allowing backward 
compatibility. 

Octet 6 to 9 (TEID/GRE field) represent either a TEID or a GRE key. If both IPv4 and IPv6 addresses are present in F- 
TEID IE, then the TEID value shall be shared by both addresses. 

Octets "m to (m+3)" and/or "p to (p+15)" (IPv4 address / IPv6 address fields), if present, contain respective address 
values. 

8.23 TMSI 

TheTMSI, unambiguously associated with a given UE and Location area, is given by: 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 88 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


TMSI 

The TMSI is defined in 3GPP TS 23.003 [2]. 





Figure 8.23-1 : TiUISI 
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8.24 Global CN-ld 

The Global CN-Id is coded as depicted in Figure 8.24-1. 



Bits 

Octets 8 7 6 5 4 3 2 1 



1 


Type = 89 (decimal) 


2 to 3 


Length = n 


4 


Spare 


Instance 


5 


MCC digit 2 


IVICC digit 1 


6 


IVINC digit 3 


MCC digit 3 


7 


MNC digit 2 


MNC digit 1 


8 to (n+4) 


CN-ld 

The CN-ld is defined in 3GPP TS 23.003 [2]. 



Figure 8.24-1 : Global CN-ld 



If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111". 

8.25 S103 PDN Data Forwarding Info (S103PDF) 

The HSGW Address and ORE Key identify a GRE Tunnel towards a HSGW over SI 03 interface for a specific PDN 
connection of the UE. The EPS Bearer IDs specify the EPS Bearers which require data forwarding that belonging to this 
PDN connection. The number of EPS bearer Ids included is specified by the value of EPS Bearer ID Number. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 90 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


HSGW Address for forwarding Length = m 




6 to (m+5) 


HSGW Address for forwarding [4.. 16] 




(m+6)- to 
(m+9) 


GRE Key 




(m+10) 


EPS Bearer ID Number = k 




(m+11) to 
(m+10+k) 


Spare 


EPS Bearer ID 





Figure 8.25-1: SI 03 PDN Data Forwarding Info 



8.26 S1 -U Data FonA/arding (S1 UDF) 

The Serving GW Address and Serving GW Sl-U TEID consists of the Sl-U Timnel information allocated by the 
Serving GW for an EPS Bearer identified by the EPS Bearer ID which requires data forwarding during active handover 
from E-UTRAN Access to cdma2000 HRPD Access. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 
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Bits 




8 7 6 5 


4 3 2 1 


1 


Type = 91 (decimal) 




id to O 


Length = n 




4 


Spare 


Instance 




5 


Spare 


EPS Bearer ID 




6 


Serving GW Address Length = m 




7 to (m+6) 


Serving GW Address [4.. 16] 




(m+7) to 
(m+10) 


Serving GW S1-U TEID 





Figure 8.26-1: S1-U Data Forwarding Info 



8.27 Delay Value 

Delay Value is coded as depicted in Figure 8.27-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 92 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Delay Value in integer multiples of 50 millisecs, or zero 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.27-1 : Delay Value 



Delay Value is set to zero in order to clear a previously set delay condition. 

8.28 Bearer Context 

Bearer Context is a grouped IE containing a number of other lEs. Which of those lEs are mandatory, optional or 
conditional and the conditions that apply are GTP message specific, and described in the corresponding subclause under 
clause 7. 

Bearer Context may be repeated within a message with exactly the same Type and Instance values to represent a list of 
Bearer Contexts. 

Bearer Context is coded as depicted in Table 8.28-1. 



Table 8.28-1 : Bearer Context Grouped Type 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 , 


Sparfi and In.^tanne flfilrls 




Information elements 


P 


Condition / Comment 


IE Type 


Ins. 












NOTE: This table uses a 5-column format in order to match the format used in subclauses of clause 7, where 
the usage of this IE is further detailed for each specific GTP message including it. 



8.29 Charging ID 

The Charging ID is coded as depicted in Figure 8.29-1. It is defined in 3GPP TS 32.251[8]. 
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Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 94 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5-8 


Charging ID value 




9-(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.29-1: Charging ID 



8.30 Charging Characteristics 

The charging characteristics information element is defined in 3GPP TS 32.251 [8] and is a way of informing both the 
SGW and PGW of the rules for producing charging information based on operator configured triggers. For the encoding 
of this information element see 3GPP TS 32.298 [9]. 







Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 95 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to 6 


Charging Characteristics value 




7 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.30-1 : Charging Characteristics 



8.31 Trace Information 

Trace Information is coded as depicted in Figure 8.31-1. See 3GPP TS 32.422 [18] for details on trace related 
information. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 96(decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


MCC digit 2 


MCC digit 1 




6 


MNC digit 3 


MCC digit 3 




7 


MNC digit 2 


MNC digit 1 




8to10 


Trace ID 




11 to 19 


Triggering Events 




20 to 21 


List of NE Types 




22 


Session Trace Depth 




23 to 34 


List of Interfaces 




35 to (n-i-4) 


IP Address of Trace Collection Entity 





Figure 8.31-1 : Trace Information 



Octets 5 to 10 represent the Trace Reference parameter as defined in 3GPP TS 32.422 [18], clause 5.6. 

Triggering Events, List of NE Types, Session Trace Depth and List of Interfaces are specified in 3GPP TS 32.422 [18] 

See 3GPP TS 24.008 [5], clause 10.5.1.4, Mobile Identity, for the coding of MCC and MNC, whose values are obtained 
from the serving PLMN that the EM/NM is managing. If MNC is 2 digits long, bits 5 to 8 of octet 6 are coded as 

"1111". 

8.32 Bearer Flags 

Bearer Flags is coded as depicted in Figure 8.32-1. 
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Bits 


Octets 


8 


7 6 5 


4 3 2 1 


1 


Type = 97 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare 


ASI 1 Vind 1 VB | PPG 




6-(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.32-1 : Bearer Flags 



The following bits within Octet 5 indicate: 

Bit 1 - PPC (Prohibit Payload Compression): This flag is used to determine whether an SGSN should attempt to 
compress the payload of user data when the users asks for it to be compressed (PPC = 0), or not (PPC = 1). 

- Bit 2 - VB (Voice Bearer): This flag is used to indicate a voice bearer when doing PS-to-CS (v)SRVCC 
handover. 

- Bit 3 - Vind (vSRVCC indicator): This flag is used to indicate that this bearer is an IMS video bearer and is 
candidate for PS-to-CS vSRVCC handover. 

- Bit 4 - ASI (Activity Status Indicator): When set to 1, this flag indicates that the bearer context is preserved in 
the CN without corresponding Radio Access Bearer established. The target S4-SGSN shall keep the bearer 
context associated with this indicator preserved. When the target S4-SGSN sends Relocation Request message 
towards the target RNC, the target S4-SGSN may not request to setup the RABs for those bearer contexts 
associated with this indicator. 

8.33 Void 

8.34 PDN Type 

The PDN Type is coded as depicted in Figure 8.34-1. 



Octets 


8 


Bits 

7 6 5 4 3 2 1 


1 


Type = 99 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare | PDN Type 




6 to n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.34-1 : PDN Type 



Table 8.34-1 : PDN Type 



PDN type value (octet 5) 
Bits 

3 2 1 

1 IPv4 
1 IPv6 
1 1 IPv4v6 

All other values are reserved. 

Bits 8-4 of octet 5 are spare and shall be coded as zero. 



8.35 Procedure Transaction ID (PTI) 

Procedure Transaction Id is coded as depicted in Figure 8.35-1. It is defined in 3GPP TS 24.301 [23], clause 9.4 and is 
coded as specified in 3GPP TS 24.007 [30], clause 1 1.2.3.1a Procedure transaction identity. 
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Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 100 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Procedure Transaction ID 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.35-1 : Procedure Transaction ID 



8.36 Void 

8.37 Void 

8.38 MIVI Context 

The MM Context information element contains the MobiUty Management, UE security parameters that are necessary to 

transfer over S3/S16/S10 interface. 

All Spare bits are set to zeros by the sender and ignored by the receiver. Spare bits in MM Context IE shall be set to I's 
before sending MM Context IE to pre-R8 SGSN. 

Security Mode indicates the type of security keys (GSM/UMTS/EPS) and Authentication Vectors (quadruplets 
/quintuplets/triplets) that are passed to the new MME/SGSN. 

The DRX parameter coding is specified in clause 10.5.5.6 of 3GPP TS 24.008 [5]. If DRXI (DRX Indicator), bit 4 of 
octet 5, is set to "1", then the DRX parameter field is present, otherwise its octets are not present. 

Uplink/downlink Subscribed UE AMBR (Aggregate Maximum Bit Rate) is coded as Unsigned32 integer values in kbps 
(1000 bps) for all non-GBR bearers according to the subscription of the user. If SAMBRI (Subscribed UE AMBR 
Indicator), bit 1 of octet 6, is set to "1", then the Uplink/downlink Subscribed UE AMBR parameter field is present, 
otherwise these parameters are not present. If no Subscribed UE AMBR is received from the HSS, the SAMBRI shall 
be set to "0". Uplink/downlink Used UE AMBR (Aggregate Maximum Bit Rate) is coded as Unsigned32 integer values 
in kbps (1000 bps) for all non-GBR bearers currently being used by the UE. If UAMBRI (Used UE AMBR Indicator), 
bit 2 of octet 6, is set to "1", then the UpUnk/downhnk Used UE AMBR parameter field is present, otherwise these 
parameters are not present. 

The encoding of Mobile Eqiupment Identity (MEI) field shall be same as specified in clause 8.10 of this specification. If 
Length of Mobile Equipment Identity is zero, then the Mobile Equipment Identity parameter shall not be present. If the 
UE is emergency attached and the UE is UlCCless or the IMSI is unauthenticated. Mobile Equipment Identity (MEI) 
shall be used as the UE identity. 

The UE Network Capability coding is specified in clause 9.9.3.34 of 3GPP TS 24.301 [23]. If Length of UE Network 
CapabiUty is zero, then the UE Network CapabiUty parameter shall not be present. 

The MS Network Capabihty coding is specified in clause 10.5.5.12 of 3GPP TS 24.008 [5]. If Length of MS Network 
CaapabiUty is zero, then the MS Network CapabiUty parameter shall not be present. 

The Voice Domain Preference and UE's Usage Setting coding is specified in clause 10.5.5.28 of 3GPP TS 24.008 [5]. If 
Length of Voice Domain Preference and UE's Usage Setting is zero, then the Voice Domain Preference and UE's Usage 
Setting parameter shall not be present. 

Used Cipher indicates the GSM ciphering algorithm that is in use. 
Used NAS Cipher indicates the EPS ciphering algorithm that is in use. 

The Access restriction data is composed of UNA(UTRAN Not Allowed), GENA(GERAN Not Allowed), GANA(GAN 
Not Allowed), INA(I-HSPA-Evolution Not Allowed), ENA(E-UTRAN Not Allowed) and HNNA(HO-To-Non-3GPP- 
Access Not Allowed). 

If the SGSN support the Higher bitrates than 16 Mbps flag, the Higher bitrates than 16 Mbps flag shall be included in 
the MM Context if: 
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- the source S4-SGSN has received "Higher bitrates than 16 Mbps flag" in the RANAP Initial UE Message or in 
RANAP Relocation Complete as defined in TS 25.413 [33| from the RNC, or 

- the source S4-SGSN has stored the "Higher bitrates than 16 Mbps flag" (received from an SGSN via the 
Identification Response, Context Response or Forward Relocation Request during earlier procedures). 

The S4-SGSN shall set the "Higher bitrates than 16 Mbps flag" to "1" if "Higher bitrates than 16 Mbps flag" is 
"allowed" and to "0" if it is "not allowed". The Length of Higher bitrates than 16 Mbps flag shall be set to zero if the 
S4-SGSN has not received the "Higher bitrates than 16 Mbps flag". 

As depicted in Figure 8.38-1, the GSM Key, Used Cipher and Authentication Triplets that are imused in the old SGSN 
shall be transmitted to the new SGSN for the GSM subscribers. 



The Authentication Triplet coding is specified in Figure 8.38-7. 



Octets 

1 

2 to 3 
4 
5 
6 

7 

8 to 15 
16toh 
(h+1)to 

(h+2) 
j to (j+3) 

0+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1) to k 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 

r+2 

(r+3) to s 
(s+1) to 
(n+4) 



6 



Bits 
5 4 



Type = 103 (decimal) 



Length = n 



Spare 



Security Mode 



Number of Triplet 



Spare 



Instance 



DRXI 



CKSN 



Spare 



UAMB 
Rl 



SAME 
Rl 



Spare 



Used Cipher 



Kc 



Authentication Triplet [P.. 4] 



DRX parameter 



Uplink Subscribed UE AMBR 



Downlink Subscribed UE AlVIBR 



Uplink Used UE AMBR 



Downlink Used UE AMBR 



Length of UE Network Capability 



UE Network Capability 



Length of MS Network Capability 



MS Network Capability 



Length of Mobile Equipment Identity (MEI) 



Mobile Equipment Identity (MEI) 



Spare 



HNNA ENA INA GANA GENA UNA 



Length of Voice Domain Preference and UE's Usage 
Setting 



Voice Domain Preference and UE's Usage Setting 



These octet(s) is/are present only if explicitly specified 



Figure 8.38-1 : GSiUI Key and Triplets 



As depicted in Figure 8.38-2, the UMTS Key, Used Cipher and Authentication Quintuplets that are unused in the old 
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in 
case the user has a ME capable of UMTS AKA. 

The Authentication Quintuplet coding is specified in Figure 8.38-8. 
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Octets 

1 

2 to 3 
4 
5 
6 

7 

8 to 23 
24 to 39 
40 to h 
(h+1)to 

(h+2) 
j to G+3) 
(j+4) to (j+7) 
i to (i+3) 
(j+12) to 
(i+4) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 

r+2 

(r+3) to s 

s+1 

s+2 
(s+3) to 

(n+4) 



Bits 
5 4 



Type = 1 04 (decimal) 



Spare 



Length = n 



Security Mode 



Number of 
Quintuplets 



Spare 



Instance 



DRXI 



CKSN/KSI 



Spare 



UAIVIB 
Rl 



SAIVIB 
Rl 



Spare 



CK 



Used Cipher 



IK 



Authentication Quintuplet [0..4] 



DRX parameter 



Uplink Subscribed UE AMBR 



Downlink Subscribed UE AMBR 



Uplink Used UE AMBR 



Downlink Used UE AMBR 



Length of UE Network Capability 



UE Network Capability 



Length of MS Network Capability 



MS Network Capability 



Length of Mobile Equipment Identity (MEI) 



Mobile Equipment Identity (MEI) 



Spare 



HNNA ENA INA GANA GENA UNA 



Length of Voice Domain Preference and UE's Usage 
Setting 



Voice Domain Preference and UE's Usage Setting 
Length of Higher bitrates than 16 Mbps flag 



Higher bitrates than 16 Mbps flag 



These octet(s) is/are present only if explicitly specified 



Figure 8.38-2: UMTS Key, Used Cipher and Quintuplets 



As depicted in Figure 8.38-3, the GSM Key, Used Cipher and Authentication Quintuplets that are unused in the old 
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in 
case the user has a ME no capable of UMTS AKA. 

The Authentication Quintuplet coding is specified in Figure 8.38-8. 
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Octets 

1 

2 to 3 
4 
5 
6 

7 

8 to 15 

16to h 
(h+1)to 

(h+2) 
j to (j+3) 
(j+4) to (j+7) 

i to (i+3) 
(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 

r+2 

(r+3) to s 

s+1 

s+2 
(s+3) to 

(n+4) 



Bits 
5 4 



Type = 1 05 (decimal) 



Length = n 



Spare 



Security Mode 



Number of 
Quintuplets 



Spare 



Instance 



DRXI 



CKSN/KSI 



Spare 



UAIVIB 
Rl 



SAIVIB 
Rl 



Spare 



Used Cipher 



Kc 



Authentication Quintuplets [0..4] 



DRX parameter 



Uplink Subscribed UE AMBR 



Downlink Subscribed UE AMBR 



Uplink Used UE AMBR 



Downlink Used UE AMBR 



Length of UE Network Capability 



UE Network Capability 



Length of MS Network Capability 



MS Network Capability 



Length of Mobile Equipment Identity (MEI) 



Mobile Equipment Identity (MEI) 



Spare 



HNNA ENA INA GANA GENA UNA 



Length of Voice Domain Preference and UE's Usage 

Setting 



Voice Domain Preference and UE's Usage Setting 
Length of Higher bitrates than 16 Mbps flag 



Higher bitrates than 16 Mbps flag 



These octet(s) is/are present only if explicitly specified 



Figure 8.38-3: GSM Key, Used Cipher and Quintuplets 



As depicted in Figure 8.38-4, the UMTS Key, KSI and unused Authentication Quintuplets in the old SGSN may be 
transmitted to the new SGSN/MME when the UMTS subscriber is attached to UTRAN/GERAN in the old system, but 
it is not allowed to send quintuplets to an MME in a different serving network domain (see 3GPP TS 33.401 [12J clause 
6.1.6). The MME may forward the UMTS Key, KSI and unused Authentication Quintuplets which were previously 
stored back to the same SGSN, for further details, refer to 3GPP TS 33.401 [12]. 

The Authentication Quintuplet coding is specified in Figure 8.38-8. 
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Octets 

1 

2 to 3 
4 
5 
6 

7 

8 to 23 
24 to 39 
40 to h 
(h+1)to 

(h+2) 
j to G+3) 

(j+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 

r+2 

(r+3) to s 

s+1 

s+2 
(3+3) to 

(n+4) 



Bits 
5 4 



Type = 1 06 (decimal) 



Spare 



Length = n 



Security Mode 



Number of 
Quintuplets 



Spare 



Instance 



DRXI 



KSI 



Spare 



UAMB 
Rl 



SAIVIB 
Rl 



Spare 



CK 



IK 



Autlientication Quintuplet [0..4] 



DRX parameter 



Uplink Subscribed UE AMBR 



Downlink Subscribed UE AMBR 



Uplink Used UE AMBR 



Downlink Used UE AMBR 



Length of UE Network Capability 



UE Network Capability 



Length of MS Network Capability 



MS Network Capability 



Length of Mobile Equipment Identity (MEI) 



Spare 



Mobile Equipment Identity (MEI) 



HNNA ENA INA GANA GENA UNA 



Length of Voice Domain Preference and UE's Usage 
Setting 



Voice Domain Preference and UE's Usage Setting 
Length of Higher bitrates than 16 Mbps flag 



Higher bitrates than 16 Mbps flag 



These octet(s) is/are present only if explicitly specified 



Figure 8.38-4: UMTS Key and Quintuplets 



As depicted in Figure 8.38-5, the current EPS Security Context, a non-current EPS Security Context (if available), and 
unused Authentication Quadruplets in the old MME may be transmitted to the new MME. If the new MME is not in the 
same serving network domain then only the current EPS Security Context may be transmitted. Authentication 
Quintuplets shall not be transmitted to the new MME even if the old MME has the Authentication Quintuplets for this 
UE. The value in Number of Quintuplets field shall be set to '0'. The reasons for not sending Quintuplets are specified 
inBGPPTS 33.401 [12] clause 6.1.6. 

The Authentication Quintuplet and Authentication Quadruplet codings are specified in Figure 8.38-8 and Figure 8.38-9 
respectively. 

The value of the NAS DownUnk Count shall be set to the value that shall be used to send the next NAS message. 

The value of the NAS UpUnk Count shall be set to the largest NAS UpUnk Count that was in a successfully integrity 
verified NAS message. 

In Figure 8.38-5, the fields for the Old EPS Security Context (i.e. octets from s to s-i-64) may be present only in SIO 
Forward Relocation Request message according to the Rules on Concurrent Running of Security Procedures, which are 
specified in 3GPP TS 33.401 [12]. The octets for Old EPS Security Context shall be present if the OSCI (Old Security 
Context Indicator), bit 1 of octet 6) is set to "1"; otherwise they shall not be present. 

If NHl_old (Next Hop Indicator for old EPS Security Context), bit 1 of octet s, is set to "1", then the parameters old NH 
(Next Hop) and old NCC (Next Hop Chaining Count) shall be present; otherwise the octets for old NH parameter shall 
not be present and the value of old NCC parameter shall be ignored by the receiver. 
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Octets 

1 

2 to 3 
4 
5 
6 



8 to 10 
11 to 13 
14 to 45 
46 tog 
(g+1)toh 
(h+1)to 
(h+2) 
pto (p+31) 
p+32 
j to G+3) 
(i+4) to (j+7) 

i to (i+3) 
(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 
s 

(s+1) to 
(s+32) 

(s+33) to 
(s+64) 
s+65 

(s+66) to t 
t to (n+4) 



Bits 
5 4 



Type = 1 07 (decimal) 



Spare 



Lengtli = n 



Security IVIode 



Number of 
Quintuplets 



SAME 
Rl 



NHI 



Instance 



DRXI 



KSIasme 



Number of 
Quadruplet 



Used MAS integrity 
protection algorithm 



UAIVIB 
Rl 



QSCI 



Used MAS Ciplier 



MAS Downlink Count 



MAS Uplink Count 



Kasme 



Authentication Quadruplet [0..4] 



Authentication Quintuplet [0..4] 



DRX parameter 



NH 



Spare 



NCC 



Uplink Subscribed UE AMBR 



Downlink Subscribed UE AMBR 



Uplink Used UE AMBR 



Downlink Used UE AMBR 



Length of UE Network Capability 



UE Network Capability 



Length of MS Network Capability 



MS Network Capability 



Length of Mobile Equipment Identity (MEI) 



Spare 



Mobile Equipment Identity (MEI) 



NHLo 
Id 



Spare 



HNNA ENA INA 



old KSIasme 



GANA GENA UNA 



Old NCC 



old Kasme 



old NH 



Length of Voice Domain Preference and UE's Usage 
Setting 



Voice Domain Preference and UE's Usage Setting 
These octet(s) is/are present only if explicitly specified 



Figure 8.38-5: EPS Security Context and Quadruplets 



If NHI (Next Hop Indicator), bit 5 of octet 5, is set to "1", then the optional parameters NH (Next Hop) and NCC (Next 
Hop Chaining Count) are both present, otherwise their octets are not present. 

As depicted in Figure 8.38-6, the old MME will derive CK' and IK' from Kasme and transmit the CK' and IK' to the new 
SGSN. Authentication Quintuplets, if available, shall be transmitted to the SGSN if, and only if the MME received 
them from this SGSN earlier, according to 3GPP TS 33.401 [12] clause 6.1.5. 

The value in Number of Quadruplets field shall be set to '0', if Authentication Quadruplets are not present. A key Kasme 
shall never be transmitted to an SGSN according to 3GPP TS 33.401 [12] clause 6.4. 

The Authentication Quintuplet and Authentication Quadruplet codings are specified in Figure 8.38-8 and Figure 8.38-9 
respectively. 

The old SGSN/MME may deliver both Authentication Quadruplets and Authentication Quintuplets it holds to the peer 
combo node to optimize the procedure. 
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Octets 

1 

2 to 3 
4 
5 
6 

7 

8 to 23 

24 to 39 
40 to g 
(g+i)toh 
(h+1)to 

(h+2) 
j to (j+3) 

(j+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1) to k 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 

r+2 

(r+3) to s 
(s+1)to 
(n+4) 



Bits 
5 4 



Type = 1 08 (decimal) 



Spare 



Length = n 



Security Mode 



Number of 
Quintuplets 



Spare 



Instance 



DRXI 



KSIfl 



Number of 
Quadruplet 



UAMB 
Rl 



SAIVIB 
Rl 



Spare 



CK 



IK 



Authentication Quadruplet [0..4] 



Authentication Quintuplet [0..4] 



DRX parameter 



Uplink Subscribed UE AMBR 



Downlink Subscribed UE AMBR 



Uplink Used UE AMBR 



Downlink Used UE AMBR 



Length of UE Network Capability 



UE Network Capability 



Length of MS Network Capability 



MS Network Capability 



Length of Mobile Equipment Identity (MEI) 



Mobile Equipment Identity (MEI) 



Spare 



HNNA ENA INA GANA GENA UNA 



Length of Voice Domain Preference and UE's Usage 
Setting 



Voice Domain Preference and UE's Usage Setting 
These octet(s) is/are present only if explicitly specified 



Figure 8.38-6: UMTS Key, Quadruplets and Quintuplets 



Bits 



Octets 

1 to 16 
17 to 20 
21 to 28 



RAND 



SRES 



Kc 



Figure 8.38-7: Authentication Triplet 



Octets 

1 to 16 

17 
18to m 
(m+1) to 
(m+1 6) 
(m+1 7) to 
(m+32) 
m+33 
(m+34) to n 



Bits 
5 4 



RAND 



XRES Length 



XRES 



CK 



IK 



AUTN Length 



AUTN 



Figure 8.38-8: Authentication Quintuplet 
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Octets 

1 to 16 

17 
18tok 
k+1 
(k+2) to m 
(m+1) to 
(m+32) 



Bits 
5 4 



RAND 



XRES Length 



XRES 



AUTN Length 



AUTN 



Kasme 



Figure 8.38-9: Authentication Quadruplet 
Table 8.38-1 : Security Mode Values 



Security Type 


Value (Decimal) 


GSM Key and Triplets 





UMTS Key, Used Cipher and Quintuplets 


1 


GSM Key, Used Cipher and Quintuplets 


2 


UMTS Key and Quintuplets 


3 


EPS Security Context and Quadruplets 


4 


UMTS Key, Quadruplets and Quintuplets 


5 


<spar8> 


6-7 



Table 8.38-2: Used NAS Cipher Values 



Cipher Algorithm 


Value (Decimal) 


No ciphering 





128-EEA1 


1 


128-EEA2 


2 


128-EEA3 


3 


EEA4 


4 


EEA5 


5 


EEA6 


6 


EEA7 


7 


<spare> 


8-15 


Table 8.38-3: Used Cipher Values 


Cipher Algorithm 


Value (Decimal) 


No ciphering 





GEA/1 


1 


GEA/2 


2 


GEA/3 


3 


GEA/4 


4 


GEA/5 


5 


GEA/6 


6 


GEA/7 


7 


8.38-4: Used NAS integrity protection algorithm V 


Integrity protection 


Value (Decimal) 


Algorithm 




No integrity protection 





128-EIA1 


1 


128-EIA2 


2 


128-EIA3 


3 


EIA4 


4 


EIA5 


5 


EIA6 


6 


EIA7 


7 
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8.39 PDN Connection 

The PDN connection is a grouped IE containing a number of other lEs and shall be coded as depicted in Table 8.39-1. 

The PDN Connection IE may be repeated within a message when more than one PDN Connection is required to be sent. 
If so, the repeated lEs shall have exactly the same Instance values to represent a list of grouped lEs. 



Table 8.39-1 : PDN Connection Grouped Type 



Octet 1 


PDN Connection IE Type = 109 (decimal) 


Octets 2 and 3 


Length = n 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 












NOTE: This table uses a 5-column format in order to match the format used in subclauses of clause 7, where 
the usage of this IE is further detailed for each specific GTP message including it. 



8.40 PDU Numbers 

The PDU Numbers information element contains the sequence number status corresponding to a Bearer context in the 
old SGSN. This information element shall be sent only when acknowledged peer-to-peer LLC operation is used for the 
Bearer context or when the "delivery order" QoS attribute is set in the Bearer context QoS profile. 

NSAPI identifies the Bearer context for which the PDU Number IE is intended. 

DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE when "delivery 
order" is set. 

UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be timnelled to the S-GW when 

"delivery order" is set. 

The Send N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer context. 
Send N-PDU Number is the N-PDU number to be assigned by SNDCP to the next down link N-PDU received from the 
S-GW. 

The Receive N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer 
context. The Receive N-PDU Number is the N-PDU number expected by SNDCP from the next up link N-PDU to be 
received from the UE. 

The PDU Number IE will be repeated for each Bearer Context for which this IE is required. 
PDU Numbers IE is coded as depicted in Figure 8.40-1. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 110 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare(0 0) 


NSAPI 




6-7 


DL GTP-U Seq 


uence Number 




8-9 


UL GTP-U Sequence Number 




10-11 


Send N-PDU Number 




12-13 


Receive N-PDU Number 




14 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.40-1 : PDU Numbers 



8.41 Packet TMSI (P-TMSI) 

The P-TMSI, unambiguously associated with a given UE and routeing area, is given by: 
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Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 111 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Packet TMSI (P-TMSI) 
The P-TMSI is defined in 3GPP TS 23.003 [2]. 





Figure 8.41-1 : Packet TMSI (P-TMSI) 



8.42 P-TMSI Signature 

The content and the coding of the P-TMSI Signature information element are defined in 3GPP TS 24.008 [5]. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 112 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


P-TMSI Signature 





Figure 8.42-1 : P-TMSI Signature 



8.43 Hop Counter 

Where Intra Domain Connection of RAN Nodes to Multiple CN Node is applied, the Hop Counter may be used to 
prevent endless loops when relaying Identification Request messages and Context Request messages. The maximum 
value is operator specific and shall not be lower than 1 . 



Octets 


8 


Bits 

7 6 5 4 3 2 1 


1 


Type =113 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Hop Counter 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.43-1 : Hop Counter 



8.44 UE Time Zone 

UE Time Zone is used to indicate the offset between universal time and local time in steps of 15 minutes of where the 
UE currently resides. The "Time Zone" field uses the same format as the "Time Zone" IE in 3GPP TS 24.008 [5]. 

UE Time Zone is coded as this is depicted in Figure 8.44-1. The value of the Time Zone field represents the time zone 
adjusted for dayhght saving time. The value of the DayUght Saving Time field specifies the adjustment that has been 
made. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 







Bits 




Octets 


8 


7 6 5 4 3 


2 1 


1 


Type = 114 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Time Zone 




6 


Spare 


Daylight 
Saving Time 




7 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.44-1 : UE Time Zone 
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Table 8.44-2 Possible values for the "Daylight Saving Time" field and their meanings. 



Daylight Saving Time 


Value (binary) 




Bit 2 


Bit 1 


No adjustment for Daylight Saving Time 








+1 hour adjustment for Daylight Saving Time 





1 


+2 hours adjustment for Daylight Saving Time 


1 





Spare 


1 


1 



8.45 Trace Reference 

Trace Reference shall be coded as depicted in Figure 8.45-1. See 3GPP TS 32.422 [18], clause 5.6, for the definition of 

Trace Reference. 

See 3GPP TS 24.008 [5], clause 10.5.1.4, Mobile Identity, for the coding of MCC and MNC, whose values are obtained 
from the serving PLMN that the EM/NM is managing. If MNC is 2 digits long, bits 5 to 8 of octet 6 are coded as 
"1111". 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 115 (decimal) 




2 to 3 


Length = 6 




4 


Spare 


Instance 




5 


MCC digit 2 


MCC digit 1 




6 


MNC digit 3 


MCC digit 3 




7 


MNC digit 2 


MNC digit 1 




8to10 


Trace ID 





Figure 8.45-1 : Trace Reference 



8.46 Complete Request Message 

The Complete Request Message is coded as depicted in Figure 8.46-1. 



Octets 


8 


Bits 

7 6 5 4 3 2 


1 


1 


Type =116 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Complete Request Message Type 




6 to (n+4) 


Complete Request Message 





Figure 8.46-1 : Complete Request Message 



Complete Request Message type values are specified in Table 8.46-1. 



Table 8.46-1 : Complete Request Message type values and their meanings 



Location Types 


Values (Decimal) 


Complete Attach Request Message 





Complete TAU Request Message 


1 


<spare> 


2-255 



8.47 GUTI 

The GUTI is coded as depicted in Figure 8.47-1. 
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Bits 



ucieis 


8 


7 6 5 


4 3 2 1 


1 


Type = 117 (decimal) 


^ 10 o 


Length = n 


4 


Spare 


Instance 


5 


MCC digit 2 


IVICC digit 1 


6 


MNC digit 3 


IVICC digit 3 


7 


MNC digit 2 


MNC digit 1 


8 to 9 


iVIME Group ID 


10 


MME Code 


1 1 to (n+4) 


M-TMSI 



Figure 8.47-1 :GUTI 



If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111". 

8.48 Fully Qualified Container (F-Container) 

Fully QuaUfied Container (F-TEID) is coded as depicted in Figure 8.48-1. 
All Spare bits are set to zeros by the sender and ignored by the receiver. 







Bits 


Octets 


8 


7 6 5 


4 3 2 1 


1 


Type = 118 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare 


Container Type 




6 to (n+4) 


F-Container field 





Figure 8.48-1 : Full Qualified Container (F-Container) 



The F-Container field shall contain one of the following information, depending of the contents of the container 
transported by the specific GTP Information Element: 

- transparent copy of the corresponding lEs (see subclause 8.2.2): 

- the "Source to Target Transparent Container" or the "Target to Source Transparent Container" as specified in 
3GPPTS 25.413 [33]; or 

- the "SON Configuration Transfer" as specified in 3GPP TS 36.413 [10]; or 

- the "eNB Status Transfer Transparent Container" as specified in 3GPP TS 36.413 [10]; or 

"Source BSS to Target BSS Transparent Container" or "Target BSS to Source ESS Transparent Container" as 
specified in 3GPP TS 48.018 [34] or 3GPP TS 25.413 [33]. 

- transparent copy of the octets of the encoded OCTET STRING of the "Source to Target Transparent Container" 
or the "Target to Source Transparent Container" specified in 3GPP TS 36.413 [10]; or 

- transparent copy of the BSSGP RIM PDU as specified in 3GPP TS 48.018 [34]; or 

- the Packet Flow ID, Radio Priority, SAPI, PS Handover XID parameters as specified in figure 8.42-2. 

NOTE 1: Annex B.2 provides further details on the encoding of Generic Transparent Containers over RANAP, Sl- 
AP and GTP. See also Annex C of 3GPP TS 36.413 [10] for further details on how the MME constructs 
the F-Container field from the Source to Target Transparent Container or Target to Source Transparent 
Container lEs received from Sl-AP. 

NOTE 2: For any other new future F-Container content types, new Container Type values may be needed, although 
use of RAT agnostic containers should be used whenever possible. 

The BSS Container IE in the Bearer Context IE in Forward Relocation Request and Context Response messages is 
coded as depicted in Figure 8.48-2. 
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Bits 


Octets 


8 


7 6 5 4 3 2 1 


6 


Spare | PHX | SARI | RP | PFI 




a 


Packet Flow ID 




b 


SAPI 1 Spare | Radio Priority 




c 


XID parameters length 




d to n 


XiD parameters 





Figure 8.48-2: BSS Container 



The flags PFI, RP, SAPI and PHX in octet 6 indicate the corresponding type of parameter (Packet FlowID, Radio 
Priority, SAPI and PS handover XID parameters) shall be present in a respective field or not. If one of these flags is set 
to "0", the corresponding field shall not be present at aU. The Spare bit shall be set to zero by the sender and ignored by 
the receiver. 

If PFI flag is set. Packet Flow ID shall be present in Octet a. 
If RP flag is set. Radio Priority shall be present in Octet b. 
If SAPI flag is set, SAPI shall be present in Octet b. 
If PHX flag is set: 

XiD parameters length is present in Octet c. 

XiD parameters are present in Octet d to n. 

8.49 Fully Qualified Cause (F-Cause) 

Fully Quahfied Cause (F- Cause) is coded as depicted in Figure 8.49-1. 







Bits 


Octets 


8 


7 6 5 


4 3 2 1 


1 


Type = 119 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare 


Cause Type 




6 to (n+4) 


F-Cause field 





Figure 8.49-1 : Full Qualified Cause (F-Cause) 



The value of Instance field of the F-Cause IE in a GTPv2 message shall indicate whether the F-Cause field contains 
RANAP Cause, BSSGP Cause or Sl-AP Cause. 

All spare bits shall be set to zeros by the sender and ignored by the receiver. 

F-Cause field is coded as follows: 

- For RANAP Cause, the F-Cause field shall contain a non-transparent copy of the cause value of the 
corresponding IE (see subclause 8.2.2), "Cause", as defined in clause 9.2.1.4 in 3GPP TS 25.413 [33]. 
Cause Type field shall be ignored by the receiver. The value of F-Cause field (which has a range of 1..512) is 
transferred over the lu interface and encoded into two octet as binary integer. 

For BSSGP Cause, the F-Cause field shall contain a non-transparent copy of the cause value of the 
corresponding IE (see subclause 8.2.2), "Cause", as defined in clause 11.3.8 in 3GPP TS 48.018 [34]. 
Cause Type field shall be ignored by the receiver. The value of F-Cause field (which has a range of 0..255) is 
transferred over the Gb interface and encoded into one octet as binary integer. 

For Sl-AP Cause, the F-Cause field shall contain a non-transparent copy of the cause value of the corresponding 
IE (see subclause 8.2.2), "Cause", as defined in clause 9.2.1.3 in 3GPP TS 36.413 [10]. 

Cause Type field shall contain the RAN Cause subcategory as specified in 3GPP TS 36.413 [10] and it shall be 
encoded as in Table 8.49-1. The value of F-Cause field (and the associated RAN cause subcategory) is 
transferred over the Sl-AP interface and encoded into one octet as binary integer. 
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Table 8.49-1 : Cause Type values and their meanings 



Cause Type 


Values (Decimal) 


Radio Network Layer 





Transport Layer 


1 


NAS 


2 


Protocol 


3 


Miscellaneous 


4 


<spare> 


5to15 



8.50 PLMN ID 

Octets 5-7 shall contain a non-transparent copy of the " PLMN Identity" parameter in 3GPP TS 36.413 [10]. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 1 20 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


PLMN ID 





Figure 8.50-1 : PLMN ID 



The encoding of the PLMN ID field is shown in Figures 8.50-2 and 8.50-3. 

If three digits are included in the MNC, octets 5 to 7 shall be encoded as shown in Figure 8.50-2. 



Bits 

Octets 8 7 6 5 4 3 2 1 



MCC digit 2 


MCC digit 1 


MNC digit 1 


MCC digit 3 


MNC digit 3 


MNC digit 2 



Figure 8.50-2: PLMN ID Parameter withi 3-digit MNC 

If only two digits are included in the MNC, octets 5 to 7 shall be encoded as shown in Figure 8.50-3 with bits 5 to 8 of 
octet 6 (MNC digit 3) coded as "1111". 



Bits 

Octets 8 7 6 5 4 3 2 1 



MCC digit 2 


MCC digit 1 


1111 


MCC digit 3 


MNC digit 2 


MNC digit 1 



Figure 8.50-3: PLMN ID Parameter with 2-digit MNC 

NOTE: The encoding is different from elsewhere in this document and is specified according to 3GPP TS 36.413 
[10]. 



8.51 Target Identification 

The Target Identification information element is coded as depicted in Figure 8.51-1. 
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Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 121 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Target Type 




6 to (n+4) 


Target ID 





Figure 8.51-1: Target identification 



Target Type values are specified in Table 8.51-1. 

The Target Type is RNC ID for SRNS relocation procedure, handover to UTRAN and RAN Information Relay towards 
UTRAN or GERAN operating in GERAN lu mode. In this case the "Target ID" field shall contain a non-transparent 
copy of the corresponding lEs (see subclause 8.2.2) and be encoded as specified in Figure 8.51-la below. The "Target 
RNC-ID" part of the "Target ID" parameter is specified in 3GPP TS 25.413 [33]. 

NOTE 1 : The ASN. 1 parameter "Target ID" is forwarded non-transparently in order to maintain backward 

compatibility. 

NOTE 2: The preamble of the "Target RNC-ID" (numerical value of e.g. 0x20) shall not be included into octets 6 
to (n+4). Also, the optional "iE-Extensions" parameter shall not be included into the GTP IE. 



Octets 

6 
7 
8 

9 to 10 
11 

12to 13 
a to (a+1) 



6 



Bits 
5 4 



MCC digit 2 



IVlNCdigitS 



MNC digit 2 



IVICC digit 1 



IVlCCdigitS 



LAC 



MNC digit 1 



RAC (see NOTE 3) 



RNC-ID 



Extended RNC-ID (optional) 



Figure 8.51 -la: Target ID for Type RNC ID 



If only two digits are included in the MNC, then bits 5 to 8 of octet 7 (MNC digit 3) shall be coded as " 11 U". 

The location area code (LAC) consists of 2 octets. Bit 8 of octet 9 is the most significant bit and bit 1 of octet 10 is the 
least significant bit. The coding of the location area code is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

The RNC-ID consists of 2 octets and contains 12 bits long value (see 3GPP TS 25.413 [7]). Bit 4 of octet 12 is the most 
significant bit and bit 1 of octet 13 is the least significant bit (bits 8 to 5 of octet 12 are set to 0). The coding of the 
RNC-ID is the responsibility of each administration. Coding using full hexadecimal representation shall be used. 

The Extended RNC-ID consists of 2 octets and contains 16 bits long value within the range 4096 to 65535. Bit 8 of 
octet a is the most significant bit and bit 1 of octet (a+1) is the least significant bit. The coding of the Extended RNC-ID 
is the responsibility of each administration. Coding using full hexadecimal representation shall be used. If the optional 
Extended RNC-ID is included, then the receiver shall ignore the RNC-ID. 

If the optional Extended RNC-ID is not included, then the length variable 'n' = 8 and the overall length of the IE is 13 
octets. Otherwise, 'n' = 10 and the overall length of the IE is 15 octets. 

NOTE 3: In the "TargetRNC-ID" ASN.l type definition in 3GPP TS 25.413 [7] the "RAC" parameter is marked as 
optional. RAC is however always available at an SGSN/MME when it sends the RAC in e.g. a GTPv2 
Forward Relocation Request message. 

The Target Type is Macro eNodeB ID for handover to E-UTRAN Macro eNodeB and RAN Information Relay towards 
E-UTRAN. In this case the coding of the Target ID field shall be coded as depicted in Figure 8.51-2. 
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Bits 




8 7 6 5 


4 3 2 1 


6 


MCC digit 2 


IVICC digit 1 




7 


MNC digit 3 


MCC digit 3 




8 


MNC digit 2 


MNC digit 1 




9 


Spare 


Macro eNodeB ID 




10 to 11 


IVIacro eNodeB ID 




12tO 13 


Tracking Area Code (TAG) 





Figure 8.51-2: Target ID for Type Macro eNodeB 



The Macro eNodeB ID consists of 20 bits. Bit 4 of Octet 9 is the most significant bit and bit 1 of Octet 1 1 is the least 
significant bit. The coding of the Macro eNodeB ID is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

The Target Type is Home eNodeB ID for handover to E-UTRAN Home eNodeB. In this case the coding of the Target 
ID field shall be coded as depicted in Figure 8.51-3. 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


6 


MCC digit 2 


MCC digit 1 




7 


MNC digit 3 


MCC digit 3 




8 


MNC digit 2 


MNC digit 1 




9 


Spare 


Home eNodeB ID 




lOto 12 


Home eNodeB ID 




13to 14 


Tracking Area Code (TAC) 





Figure 8.51-3: Target ID for Type Home eNodeB 



The Home eNodeB ID consists of 28 bits. See 3GPP TS 36.413 [10]. Bit 4 of Octet 9 is the most significant bit and bit 
1 of Octet 12 is the least significant bit. The coding of the Home eNodeB ID is the responsibility of each administration. 
Coding using fuU hexadecimal representation shall be used. 

The Target Type is Cell Identifier for handover to GERAN and RAN Information Relay towards GERAN. In this case 
the coding of the Target ID field shall be same as the Octets 3 to 10 of the Cell Identifier lEI in 3GPP TS 48.018 [34]. 



Table 8.51-1 : Target Type values and their meanings 



Target Types 


Values (Decimal) 


RNC ID 





Macro eNodeB ID 


1 


Cell Identifier 


2 


Home eNodeB ID 


3 


<spare> 


4 to 255 



8.52 Void 

8.53 Packet Flow ID 

The Packet Flow Id information element contains the packet flow identifier assigned to an EPS Bearer context as 
identified by EPS Bearer ID. 

The spare bits 8 to 5 in octet 5 indicate unused bits, which shall be set to by the sending side and which shall not be 
evaluated by the receiving side. 
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Bits 




Octets 


8 


7 6 5 


4 3 2 


1 


1 


Type = 1 23 (decimal) 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare 


EBI 




6 to (n+4) 


Packet 


Flow ID 





Figure 8.53-1 : Packet Flow ID 



8.54 RAB Context 

The RAB Context shall be coded as is depicted in Figure 8.54- 



Octets 

1 

2 to 3 
4 
5 

6 to 7 
8 to 9 
10 to 11 
12tO 13 



Bits 
5 4 



Type = 1 24 (decimal) 



Length = 9 



Spare 



Spare 



Instance 



NSAPI 



PL GTP-U Sequence Number 



UL GTP-U Sequence Number 



PL PDCP Sequence Number 



UL PDCP Sequence Number 



Figure 8.54-1 : RAB Context 

The RAB Context IE may be repeated within a message with exactly the same Type and Instance to represent a list. 

The RAB context information element contains sequence number status for one RAB in RNC, which corresponds to 
one PDP context. The RAB contexts are transferred between the RNCs via the SGSNs at inter SGSN hard handover. 

NSAPI identifies the PDP context and the associated RAB for which the RAB context IE is intended. 

DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE. 

UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the SGW. 

DL PDCP Sequence Number is the number for the next downlink PDCP-PDU to be sent to the UE. 

UL PDCP Sequence Number is the number for the next uplink PDCP-PDU to be received from the UE. 

8.55 Source RNC PDCP context info 

The purpose of the Source RNC PDCP context info IE is to transfer RNC PDCP context information from a source 
RNC to a target RNC during an SRNS relocation. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 1 25 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


RRC Container 





Figure 8.55-1 : Source RNC PDCP context info 



8.56 Port Number 

Port Number is coded as depicted in Figure 8.56-1. 
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Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 1 26 (decimal) 




2 to 3 


Length = 2 




4 


Spare Instance 




5 to 6 


Port Number 




7 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.56-1: UDP Source Port Number 



8.57 APN Restriction 

The APN Restriction information element contains an unsigned integer value indicating the level of restriction imposed 
on EPS Bearer Contexts created to the associated APN. 

The APN Restriction IE is coded as depicted in Figure 8.57-1: 



Octets 


Bits 

8 7 6 5 4 3 2 1 


1 


Type = 127 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Restriction Type value 




6 to (n+4) 


These octet(s) Is/are present only If explicitly specified 





Figure 8.57-1 : APN Restriction Type Information Element 



An APN Restriction value may be configured for each APN in the PGW. It is used to determine, on a per UE basis, 
whether it is allowed to estabhsh EPS bearers to other APNs. 



Table 8.57-1 : Valid Combinations of APN Restriction 



Maximum 
APN 


Type of APN 


Application Example 


APN Restriction Value allowed to be 
established 


Restriction 








Value 











No Existing Contexts or Restriction 


All 


1 


Public-1 


MMS 


1,2,3 


2 


Publlc-2 


Internet 


1,2 


3 


Private- 1 


Corporate (e.g. who use 
MMS) 


1 


4 


Prlvate-2 


Corporate (e.g. who do not 
use MMS) 


None 



8.58 Selection IVIode 

The Selection mode information element indicates the origin of the APN in the message. 







Bits 




Octets 


8 


7 6 5 4 3 


2 1 


1 


Type = 128 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare 


Selec. Mode 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.58-1 : Selection Mode Information Element 
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Table 8.58-1 : Selection Mode Values 



Selection mode value 


Value (Decimal) 


MS or network provided APN, subscribed verified 





IVIS provided APN, subscription not verified 


1 


Network provided APN, subscription not verified 


2 


For future use. Shall not be sent. If received, shall be interpreted as the value "2". 


3 



8.59 Source lijentification 

The Source Identification information element is coded as depicted in Figure 8.59-1. 





Bits 




Octets 


8 7 6 5 4 3 2 


1 


1 


Type = 1 29 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to 12 


Target Cell ID 




13 


Source Type 




14 to (n+4) 


Source ID 





Figure 8.59-1 : Source Identification 



The Target Cell ID shall be same as the Octets 3 to 10 of the Cell Identifier lEI in 3GPP TS 48.018 [34]. 
Source Type values are specified in Table 8.59-1. 

If the Source Type is Cell ID, this indicates PS handover from GERAN A/Gb mode. In this case the coding of the 
Source ID field shall be same as the Octets 3 to 10 of the Cell Identifier lEl in 3GPP TS 48.018 [34]. 

If the Source Type is RNC ID, this indicates PS handover from GERAN lu mode or for inter-RAT handover from 
UTRAN. In this case the Source ID field shall include a transparent copy of the corresponding parameter (see subclause 
8.2.2), the Source RNC-ID as specified within the "Source ID" parameter in 3GPP TS 25.413 [33]. 

NOTE: In fact, the ASN.l/PER encoded binary value of the "Source RNC ID" shall be copied into octets 14 to 
(n+4). 



Table 8.59-1 : Source Type values and their meanings 



Source Types 


Values (Decimal) 


Cell ID 





RNC ID 


1 


reserved (NOTE) 


2 


<spare> 


3-255 


NOTE: This value was allocated in an earlier version of the protocol and 
shall not be used. 



8.60 Void 

8.61 Change Reporting Action 

Change Reporting Action IE is coded as depicted in Figure 8.61-1. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 131 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Action 





Figure 8.61-1: Change Reporting Action 
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Table 8.61-1 : Action values 



Action 


value (uecimai; 


Stop Reporting 


U 


Start Reporting CGI/SAI 


1 


Start Reporting RAI 


2 


Start Reporting TAI 


3 


Start Reporting ECGI 


4 


Start Reporting CGI/SAI and RAI 


5 


Start Reporting TAI and ECGI 


6 


<spare> 


7-255 



Stop Reporting stops all reporting action types. 



8.62 Fully qualified PDN Connection Set Identifier (FQ-CSID) 

A fully qualified PDN Connection Set Identifier (FQ-CSID) identifies a set of PDN connections belonging to an 
arbitrary number of UEs on a MME, SOW, TWAN, ePDG or PGW. The FQ-CSID is used on S5, S8, S2a, S2b and Sll 

interfaces. 

The size of CSID is two octets. The FQ-CSID is coded as follows: 





Bits 


Octets 


8 7 6 5 


4 3 2 1 


1 


Type = 132 (decimal) 




2 to 3 


Lengtli = n 




4 


Spare 


Instance 




5 


Node-ID Type 


Number of CSIDs=m 




6to p 


Node-ID 




(p+1)to 


First PDN Connection Set Identifier (CSID) 




(p+2) 








(p+3) to 
(p+4) 


Second PDN Connection Set Identifier (CSID) 










q to q+1 


m-th PDN Connection Set Identifier (CSID) 




(q+2) to 
(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.62-1 : FQ-CSID 



Where Node-ID Type values are: 

indicates that Node-ID is a global unicast IPv4 address and p = 9. 

1 indicates that Node-ID is a global unicast IPv6 address and p = 21 . 

2 indicates that Node-ID is a 4 octets long field with a 32 bit value stored in network order, and p= 9. The coding 

of the field is specified below: 

- Most significant 20 bits are the binary encoded value of (MCC * 1000 + MNC). 

- Least significant 12 bits is a 12 bit integer assigned by an operator to an MME, SGW, TWAN, ePDG or PGW. 
Other values of Node-ID Type are reserved. 

Values of Number of CSID other than 1 are only employed in the Delete PDN Connection Set Request. 

The node that creates the FQ-CSID, (i.e. MME for MME FQ-CSID, SGW for SGW FQ-CSID, TWAN for TWAN FQ- 
CSID, ePDG for ePDG FQ-CSID and PGW for PGW FQ-CSID), is responsible for making sure the Node-ID is 
globally unique and the CSID value is unique within that node. 

When a FQ-CSID is stored by a receiving node, it is stored on a PDN basis even for messages impacting only one 
bearer (i.e. Create Bearer Request). See 3GPP TS 23.007 [17] for further details on the CSID and what specific 
requirements are placed on the PGW, TWAN, ePDG, SGW and MME. 
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8.63 Channel needed 

The Channel needed shall be coded as depicted in Figure 8.63-1. Channel needed is coded as the lEI part and the value 
part of the Channel Needed IE defined in 3GPP TS 44.018[28] 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 1 33 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Channel Needed 





Figure 8.63-1 : Channel needed 



8.64 eMLPP Priority 

The eMLPP-Priority shall be coded as depicted in Figure 8.64-1. The eMLPP Priority is coded as the value part of the 
eMLPP-Priority IE defined in 3GPP TS 48.008 [29] (not including 3GPP TS 48.008 lEI and 3GPP TS 48.008 [29] 
length indicator). 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 1 34 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


eMLPP-Priority 





Figure 8.64-1 : elUlLPP Priority 



8.65 Node Type 

Node Type is coded as this is depicted in Figure 8.65-1. 



Octets 


8 


Bits 

7 6 5 4 3 2 1 


1 


Type = 135 (decimal) 




2-3 


Length = n (decimal) 




4 


Spare Instance 




5 


Node Type 




6-(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.65-1 : Node Type 



Node type values are specified in Table 8.65-1. 



Table 8. 65-1 : Node Type values 



Node Types 


Values (Decimal) 


MME 





SGSN 


1 


<spare> 


2-255 



If with a Release Access Bearers Request, or Suspend Notification, or Resume an SGW receives a semantically 
erroneus/unexpected Originating Node, then the following applies: 

If SGW has an active connection to an MME, but the Originating Node IE contains value "SGSN", then the 
SGW shall not release the user plane and shall send a response to the SGSN with some appropriate cause value 
and the SGW. 

- If SGW has an active connection to an S4-SGSN, but the Originating Node IE contains value "MME", then the 
SGW shall not release the user plane and shall send a response to the MME with some appropriate cause value. 
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8.66 Fully Qualified Domain Name (FQDN) 

Fully Qualified Domain Name (FQDN) is coded as depicted in Figure 8.66-1. 



Octets 


8 


Bits 

7 6 5 4 3 2 1 


1 


Type = 136 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


FQDN 




Figure 8.66-1 


: Fully Qualified Domain Name (FQDN) 



The FQDN field encoding shall be identical to the encoding of a FQDN within a DNS message of section 3. 1 of IETF 
RFC 1035 [31] but excluding the trailing zero byte. 

NOTE 1: The FQDN field in the IE is not encoded as a dotted string as commonly used in DNS master zone files. 

A "PGW node name" IE in S3/S10/S16 OTP messages shall be a PGW host name as per subclause 4.3.2 of 3GPP TS 
29.303 [32] when the PGW FQDN IE is populated from 3GPP TS 29.303 [32] procedures. Specifically, the first DNS 
label is either "topon" or "topoff ', and the canonical node name of the PGW starts at the third label. The same rules 
apply to "SGW node name" IE on S3/S10/S16. 

NOTE 2: The constraint of subclause 4.3.2 of 3GPP TS 29.303 format is on populating the IE by 3GPP nodes for 
3GPP nodes, the receiver shall not reject an IE that is otherwise correctly formatted since the IE might be 
populated for a non-3GPP node. 

An "MME node name" IE and an "SGSN node name" IE in S3 GTP messages indicate the associated ISR node when 
the ISR becomes active. 

8.67 Private Extension 

Private Extension is coded as depicted in Figure S.Figure 8.67-1. 

Enterprise ID can be found at lANA web site ( http ://w w w . iana. org/as signments/enterprise-numbers ) . 







Bits 






Octets 


8 


7 6 5 4 


3 2 


1 


1 


Type = 255 (decimal) 




2 to 3 


Length = n 




4 




Spare 


Instance 






5 to 6 


Enterprise ID 




7 to (n+4) 


Proprietary value 





Figure 8.67-1. Private Extension 



8.68 Transaction Identifier (Tl) 

Transaction Identifier is coded as depicted in Figure 8.68-1. It is defined in 3GPP TS 24.301 [23], clause 9.9.4.17 and is 
coded as specified in 3GPP TS 24.007 [30], clause 11.2.3.1.3 Transaction identifier. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 137 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


Transaction Identifier 





Figure 8.68-1 : Transaction Identifier 
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8.69 MBMS Session Duration 

The MBMS Session Duration is defined in 3GPP TS 23.246 |37|. The MBMS Session Duration information element 
indicates the estimated session duration of the MBMS service data transmission if available. The payload shall be 
encoded as per the MBMS-Session-Duration AVP defined in 3GPP TS 29.061 [38], excluding the AVP Header fields 
(as defined in IETF RFC 3588 [39], section 4.1). 







Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 138 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to 7 


MBMS Session Duration 




8 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.69-1 : MBMS Session Duration 



8.70 IVIBIVIS Service Area 

The MBMS Service Area is defined in 3GPP TS 23.246 [37]. The MBMS Service Area information element indicates 
the area over which the Multimedia Broadcast Multicast Service is to be distributed. The payload shall be encoded as 
per the MBMS-Service-Area AVP defined in 3GPP TS 29.061 [38], excluding the AVP Header fields (as defined in 
IETF RFC 3588 [39], section 4.1). 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 1 39 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


MBMS Service Area 





Figure 8.70-1 : MBMS Service Area 



8.71 IVIBIVIS Session Identifier 

The MBMS Session Identifier information element contains a Session Identifier allocated by the BM-SC. The MBMS 
Session Identifier value part consists of 1 octet. The content and the coding are defined in 3GPP TS 29.061 [38]. 







Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 1 40 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


MBMS Session Identifier 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.71-1 : MBMS Session Identifier 



8.72 MBMS Flow Identifier 

The MBMS Flow Identifier is defined in 3GPP TS 23.246 [37]. In broadcast mode, the MBMS Flow Identifier 
information element is included in MBMS Session Management messages to differentiate the different sub-sessions of 
an MBMS user service (identified by the TMGI) providing location-dependent content. The payload shall be encoded as 
per the MBMS-Flow- Identifier AVP defined in 3GPP TS 29.061 [38], excluding the AVP Header fields (as defined in 
IETF RFC 3588 [39], section 4.1). 
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Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 141 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to 6 


MBMS Flow Identifer 




7 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.72-1: lUIBIUIS Flow Identifier 



8.73 MBMS IP Multicast Distribution 

The MBMS IP Multicast Distribution IE is sent by the MBMS GW to the MME/SGSN in the MBMS Session Start 
Request. Source Specific Multicasting is used according to IETF RFC 4607 [40]. 

The IP Multicast Distribution Address and the IP Multicast Source Address fields contain the IPv4 or IPv6 address. The 
Address Type and Address Length fields shall be included in each field: 

- The Address Type, which is a fixed length code (of 2 bits) identifying the type of address that is used in the 
Address field. 

The Address Length, which is a fixed length code (of 6 bits) identifying the length of the Address field. 

The Address, which is a variable length field shall contain either an IPv4 address or an IPv6 address. 
Address Type and Address Length 4 shall be used when Address is an IPv4 address. 
Address Type I and Address Length 16 shall be used when Address is an IPv6 address. 
Other combinations of values are not valid. 

MBMS HC Indicator represents an indication if header compression should be used for MBMS user plane data, as 
specified in 3GPP TS 25.413 [33]. MBMS HC Indicator field is encoded as a one octet long enumeration. 

NOTE: Currently, 3GPP TS 25.413 [33] specifies two enumeration values: (indicates "uncompressed-header") 

and 1 (indicates "compressed-header"). 

Common Tunnel Endpoint Identifier is allocated at the source Tunnel Endpoint and signalled to the destination Tunnel 
Endpoint. There is one Common Timnel Endpoint Identifier allocated per MBMS bearer service. The recommendations 
on how to set the value of C-TEID are provided in 3GPP TS 23.246 [37]. 



Octets 


8 7 


Bits 

6 5 4 3 2 1 


1 


Type = 1 42 (decimal) 




2 to 3 


Length=n 




4 


Spare Instance 




5 to 8 


Common Tunnel Endpoint Identifier 




9 


Address Type 


Address Length 




lOtoK 


IP Multicast Distribution Address (IPv4 or IPv6) 




K+1 


Address Type 


Address Length 




(k+2) to m 


IP IVIulticast Source Address (IPv4 or IPv6) 




m+1 


MBMS HC Indicator 




(m+2) to n 


These octet(s) is/are present only if explicitly specified 





Figure 8.73-1: MBMS IP Multicast Distribution 



8.74 MBMS Distribution Acknowledge 

The MBMS Distribution Acknowledge IE is sent by the SGSN to the MBMS GW in the MBMS Session Start Response 
and MBMS Session Update Response. It is used by the MBMS GW to decide if an IP Multicast Distribution user plane 
shall be established, or a normal point-to-point user plane, or both. 
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Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 143 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare Distr Ind 




6 to n+4 


These octet{s) is/are present only if explicitly specified 





Figure 8.74-1 : MBMS Distribution Acl(nowledge 



Table 8.74-1 : Distribution indication values 



Distribution Indication 


Value (Decimal) 


No RNCs have accepted IP multicast distribution 





All RNCs have accepted IP multicast distribution 


1 


Some RNCs have accepted IP multicast distribution 


2 


Spare. For future use. 


3 



8.75 User CSG Information (UCI) 

User CSG Information (UCI) is coded as depicted in Figure 8.75-1. The CSG ID is defined in 3GPP TS 23.003 [2]. 



Bits 

Octets 8 7 6 5 4 3 2 1 



1 


Type 


= 145 


2 to 3 


Length = n 


4 


Spare 


Instance 


5 


MCC digit 2 


IVICC digit 1 


6 


MNC digit 3 


MCC digit 3 


7 


MNC digit 2 


MNC digit 1 


8 


spare 


1 CSG ID 


9to11 


CSG ID 


12 


Access mode spare LCSG CIVII 


13 to (n+4) 


These octet(s) is/are present only if explicitly specified 



Figure 8.75-1 : User CSG information 



For two digits in the MNC, bits 5 to 8 of octet 6 are coded as " 11 11 " . 

The CSG ID consists of 4 octets. Bit 3 of Octet 8 is the most significant bit and bit 1 of Octet 11 is the least significant 
bit. The coding of the CSG ID is the responsibility of the operator that allocates the CSG ID by administrative means. 
Coding using full hexadecimal representation shall be used. 

Access mode values are specified in Table 8.75-1. 



Table 8.75-1 : Access mode values and their meanings 



Access Mode 


Values (Decimal) 


Closed Mode 





Hybrid Mode 


1 


Reserved 


2-3 



Leave CSG flag (LCSG) shall be set to "1" if UE leaves CSG cell/Hybrid cell, and in this case, the receiving node shall 
ignore the rest information in the IE. 

CSG Membership Indication (CMI) values are specified in Table 8.75-2. CMI shall be included in the User CSG 
Information if the Access mode is Hybrid Mode. For the other values of Access Mode, the CMI shall be set to by the 
sender and ignored by the receiver. 
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Table 8.75-2: CSG Membership indication (ClUll) 



CMI 


Values (Decimal) 


Non CSG membership 





CSG membership 


1 



8.76 CSG Information Reporting Action 

CSG Infomation Reporting Action is coded as depicted in Figure 8.76-1. 



Bits 

Octets 8 7 6 5 4 3 2 1 



1 


Type = 146 


2 to 3 


Length = n 


4 


Spare 


Instance 




5 


Spare 


UCIU 


UCIS 


UCIC 






HC 


HC 


SG 


6 to (n+4) 


These octet(s) is/are present only 


f explicitly specified 



Figure 8.76-1 : CSG Reporting Action 



The following bits within Octet 5 shall indicate: 

• Bit 1 - UCICSG: When set to " 1 ", shall indicate to start reporting User CSG Info when the UE 
enters/leaves/access through the CSG Cell. 

• Bit 2 - UCISHC: When set to " 1 ", shall indicate to start reporting User CSG Info when the UE 
enters/leaves/access through Subscribed Hybrid Cell. 

• Bit 3 - UCIUHC: When set to " 1 ", shall indicate to start Reporting User CSG Info when the UE 
enters/leaves/access through Unsubscribed Hybrid Cell. 

AH the bits 1 to 3 shall be set to to stop reporting User CSG Info. 

8.77 RFSP Index 

Index to RAT/Frequency Selection Priority (RFSP Index) is coded as depicted in Figure 8.77-1, and contains a non- 
transparent copy of the corresponding IE (see subclause 8.2.2), "Subscriber Profile ID for RAT/Frequency Selection 
Priority (SPRIFP)" as specified in 3GPP TS 36.413 [10]. The SPIRFP is an integer between 1 and 256 and is encoded 
as an unsigned integer, which requires the two octets specified for the RFSP Index parameter. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 144 (decimal) 




2 to 3 


Length = 2 




4 


Spare Instance 




5 to 6 


RFSP Index 





Figure 8.77-1. RFSP Index 



8.78 CSG ID 

CSG ID is coded as depicted in Figure 8.78-1. The CSG ID is defined in 3GPP TS 23.003 [2]. 
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Bits 

Octets 8 7 6 5 4 3 2 1 



1 


Type = 1 47 


2 to 3 


Length = n 


4 


Spare Instance 


5 


Spare | CSG ID 


6 to 8 


CSG ID 


9 to (n+4) 


These octet(s) is/are present only if explicitly specified 



Figure 8.78-1: CSG ID 



The CSG ID consists of 4 octets. Bit 3 of Octet 4 is the most signiiicaiit bit and bit 1 of Octet 7 is the least significant 
bit. The coding of the CSG ID is the responsibility of the operator that allocates the CSG ID by administrative means. 
Coding using full hexadecimal representation shall be used. 

8.79 CSG Membership Indication (CMI) 

CSG Membership Indication is coded as depicted in Figure 8.79-1. 





Bits 




Octets 


8 7 6 5 4 


3 2 1 


1 


Type = 148 




2 to 3 


Length = n 




4 


Spare 


Instance 




5 


Spare 


1 CMI 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.79-1 : CSG lUlembership indication 



Tabie 8.79-1 : void 

CSG Membership Indication (CMI) values are specified in Table 8.79-2. 



Tabie 8.79-2: CSG iUlembersliip indication (CIVII) 



ClUII 


Values (Decimal) 


CSG membership 





Non CSG membership 


1 



8.80 Service indicator 

Service indicator is coded as depicted in Figure 8.80-1. 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 149 (decimal) 




2 to 3 


Length = 1 




4 


Spare Instance 




5 


Service indicator 





Figure 8.80-1. Service indicator 



Service indicator values are specified in Table 8.80-1. 



Tabie 8.80-1 : Service indicator vaiues 



Service Indicator 


Values (Decimal) 


<spare> 





CS call indicator 


1 


SMS indicator 


2 


<spare> 


3-255 
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8.81 Detach Type 

Detach Type is coded as depicted in Figure 8.81-1. 



Bits 

Octets 8 7 6 5 4 3 2 1 

1 Type = 1 50 (decimal) 

2 to 3 Length = 1 

4 Spare | Instance 

5 I Detach Type 

Figure 8.81-1: Detacli Type 



Table 8.81-1 : Detach Type values 



Detacii Types 


Vaiues (Decimai) 


<reserved> 





PS Detach 


1 


Combined PS/CS Detach 


2 


<spare> 


3-255 



8.82 Local Distinguished Name (LDN) 

Represents the Local Distinguished Name (LDN) of the network element (see 3GPP TS 32.423 [44]). 







Bits 




Octets 


8 


7 6 5 4 3 2 


1 


1 


Type = 151 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to (n+4) 


LDN 





Figure 8.82-1 : Local Distinguished Name (LDN) 



The LDN field consists of 1 up to a maximum of 400 ASCII characters, i.e., from 1 up to a maximum of 400 octets. 

8.83 Node Features 

Node Features IE is coded as depicted in Figure 8. 83-1. 







Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 1 52 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Supported-Features 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.83-1 : Node Features IE 



The Node Features IE takes the form of a bitmask where each bit set indicates that the corresponding feature is 
supported. Spare bits shall be ignored by the receiver. The same bitmask is defined for all GTPv2 interfaces. 

The following table specifies the features defined on GTPv2 interfaces and the interfaces on which they apply. 
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Table 8.83-1 : Node Features on GTPv2 interfaces 





Feature 






5/1 


PRN 


S11, S4 


PGW Restart Notification. 
If both the SGW and the MME/S4-SGSN support 
this feature, the SGW shall send PGW Restart 
Notification message to the MME/S4-SGSN when 
the SGW detects that the peer PGW has restarted, 
and the SGW may send PGW Restart Notification 
message when the SGW detects that the peer PGW 
has failed and not restarted, as specified in 
subclause 7.9.5. 


5/2 


MABR 


S11 


Modify Access Bearers Request. 
If both the SGW and the MME support this feature, 
the MME may modify the S1 -U bearers of all the 
PDN connections of the UE by sending a Modify 
Access Bearers Request message as specified in 
subclause 7.2.24. 


5/3 


NTSR 


S11/S4 


Network Triggered Service Restoration procedure. 
If both the SGW and the MME/S4-SGSN support 
this feature (see 3GPP TS 23.007 [17]), the SGW 
shall send a Downlink Data Notification message 
including the IMSI to the MME/S4-SGSN on the 
TEID as part of a network triggered service 
restoration procedure. 


Feature Octet / Bit: The octet and bit number within the Supported-Features IE, e.g. "5 / 1 ". 
Feature: A short name that can be used to refer to the octet / bit and to the feature. 
Interface: A list of applicable interfaces to the feature. 
Description: A clear textual description of the feature. 



No features have been defined on the following GTPv2 interfaces in this version of the specification: S2a, S2b, S5, S8, 
SIO, S3, S16, Sv, SlOl, Sm, Sn. 



8.84 MBMS Time to Data Transfer 

The MBMS Time to Data Transfer indicates the minimum time occurring between the transmission of the MBMS 
SESSION START REQUEST message and the actual start of the data transfer. It is coded as shown in figure 8.84-1. 
Octet 5 is coded as the value part of the Time to MBMS Data Transfer IE defined in 3GPP TS 48.018 [34] (not 
including the lEI and length indicator octets specified in 3GPP TS 48.018 [34]). 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 153 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


MBMS Time to Data Transfer value part 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.84-1 : lUIBIUIS Time to Data Transfer 



8.85 Throttling 

ThrottUng is coded as depicted in Figure 8.85-1. 
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Bits 

8 7 6 5 4 3 2 1 


1 


Type = 154 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Throttling Delay Unit Throttling Delay Value 




6 


Throttling Factor 




7 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.85-1 : Throttling 



Table 8.85.1: Throttling information element 



Throttling Delay (octet 5) 

Bits 5 to 1 represent the binary coded timer value. 

Bits 6 to 8 defines the timer unit for the timer as follows: 

Bits 

876 

value is incremented in multiples of 2 seconds 
1 value is incremented in multiples of 1 minute 
1 value is incremented in multiples of 10 minutes 

1 1 value is incremented in multiples of 1 hour 

1 value is incremented in multiples of 10 hours 
1 1 1 value indicates that the timer is deactivated. 

Other values shall be interpreted as multiples of 1 minute. 

Throttling Factor (octet 6) 

The Throttling Factor indicates a percentage and may tal<e binary coded integer 
values from and including up to and including 100. Other values shall be 
considered as 0. 



8.86 Allocation/Retention Priority (ARP) 

Allocation/Retention Priority (ARP) is coded as depicted in Figure 8.86-1. 

Bits 

Octets 8 7 6 5 4 3 2 1 

1 Type = 155 (decimal) 

2 to 3 Length = n 

4 Spare | Instance 

5 Spare | PCI | PL | Spare | PVT 
6 to (n+4) I These octet(s) is/are present only if explicitly specified | 

Figure 8.86-1 : Allocation/Retention Priority (ARP) 

The meaning and value range of the parameters within the ARP are defined in 3GPP TS 29.212 [29]. The bits within the 
octet 5 are: 

- Bit 1 - PVI (Pre-emption Vulnerability): See 3GPP TS 29.212[29], clause 5.3.47 Pre-emption- Vulnerability 
AVP. 

Bit 2 - spare 

- Bits 3 to 6 - PL (Priority Level): See 3GPP TS 29.212[29], clause 5.3.45 ARP- Value AVP. PL encodes each 
priority level defined for the ARP- Value AVP as the binary value of the priority level. 

- Bit 7 - PCI (Pre-emption Capabihty): See 3GPP TS 29.212[29], clause 5.3.46 Pre-emption-Capabihty AVP. 

- Bit 8 - spare. 
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8.87 EPC Timer 

The purpose of the EPC Timer information element is to specify EPC specific timer values. 
The EPC Timer information element is coded as shown in figure 8.87-1 and table 8.87.1 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 56 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Timer unit Timer value 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.87-1 : EPC Timer 



Table 8.87.1 : EPC Timer information element 



Timer value 

Bits 5 to 1 represent the binary coded timer value. 

Timer unit 

Bits 6 to 8 defines the timer value unit for the EPC timer as follows: 

Bits 

876 

value is incremented in multiples of 2 seconds 
1 value is incremented in multiples of 1 minute 
1 value is incremented in multiples of 10 minutes 

1 1 value is incremented in multiples of 1 hour 

1 value is incremented in multiples of 10 hours 
1 1 1 value indicates that the timer is infinite 

Other values shall be interpreted as multiples of 1 minute in this version of the 
protocol. 

Timer unit and Timer value both set to all "zeros" shall be interpreted as an 
indication that the timer is stopped. 



8.88 Signalling Priority Indication 

The Signalling Priority Indication information element contains signalling priority indications received from the UE for 
a specific PDN cormection. 

The SignalUng Priority Indication information element is coded as shown in figure 8.88-1. 



Bits 

Octets 8 7 6 5 4 3 2 1 

1 Type = 157 (decimal) 

2 to 3 Length = n 

4 Spare | Instance 

5 Spare | LAPI 
6 to (n+4) I These octet(s) is/are present only if explicitly specified 

Figure 8.88-1 : Signalling Priority Indication 

The following bits within Octet 5 shall indicate: 

Bit 8 to 2 - Spare, for future use and set to zero. 
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Bit 1 - LAPI (Low Access Priority Indication): This bit defines if the UE indicated low access priority when 
estabhshing the PDN connection. It shall be encoded as the Low Priority parameter of the Device Properties IE 
in 3GPP TS 24.008 [5]. The receiver shall assume the value "0" if the Signalling Priority Indication IE is 
applicable for a message but not included in that message by the sender. The low access priority indication may 
be included in charging records. 

8.89 Temporary Mobile Group Identity (TIVIGI) 

The TMGI contains the Temporary Mobile Group Identity allocated to the MBMS Bearer Service. The BM-SC always 
includes the MCC and MNC when allocating the TMGI, see 3GPP TS 29.061 [38]. 

It is coded as specified in Figure 8.89-1. 







Bits 


Octets 


8 


7 6 5 4 3 2 1 


1 


Type = 158 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5-10 


TMGI 




11-(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.89-1 : TMGI 



Octets 5 to 10 shall be encoded as octets 3 to octet 8 in the figure 10.5.154 of 3GPP TS 24.008 [5]. 



8.90 Additional IVIIVI context for SRVCC 

The additional MM Context for SRVCC information element contains mobile station classmarks, supported codec list 
that are necessary for the MME/S4-SGSN to perform SRVCC as defined in 3GPP TS 23.216 [43]. The coding of 
Mobile Station Classmarks and Supported Codec List fields include the IE value part as it is specified in 3GPP TS 
24.008 [5]. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 59 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Length of the Mobile Station Classmark 2 




6 to a 


Mobile Station Classmark 2 




b 


Length of the Mobile Station Classmark 3 




(b+1)toc 


Mobile Station Classmark 3 




d 


Length of the Supported Codec List 




(d+1) to e 


Supported Codec List 




(e+1) to 
(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.90-1 : Additional lUlM context for SRVCC 



8.91 Additional flags for SRVCC 

Additional flags for SRVCC is coded as depicted in Figure 8.91-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 60 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare | VP | ICS 




6-(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.91-1 : Additional flags for SRVCC 
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The following bits within Octet 5 indicate: 

- Bit 1 - ICS (IMS Centralized Service): This flag indicates that UE supports ICS specific service as specified in 
3GPPTS 23.292 [47]. 

- Bit 2 - VF (vSRVCC Flag): This flag indicates that the user is subscribed to the vSRVCC. 



8.92 Void 



8.93 MDT Configuration 

MDT Configuration is coded as depicted in Figure 8.93-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 162 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Job Type 




6 to 9 


List of Measurements 




10 


Reporting Trigger 




11 


Report Interval 




12 


Report Amount 




13 


Event Threshold for RSRP 




14 


Event Threshold for RSRQ 




15 


Length of Area Scope 




ptoq 


Area Scope 




r to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.93-1 : IVIDT Configuration 



Parameters in octets 5 to 14 and p to q are specified in 3GPP TS 32.422 [18]. If Length of Area Scope equals zero, then 
Area Scope octets p to q are not present. 



8.94 Additional Protocol Configuration Options (APCO) 

The Additional Protocol Configuration Options (APCO) information element is used to exchange additional protocol 
configuration options between the TWAN/ePDG and the PGW. 

The Additional Protocol Configuration Options information element is specified in 3GPP TS 29.275 [26] and its GTPv2 
coding is shown in figure 8.94-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 163 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 to m 


Additional Protocol Configuration Options (APCO) 




(m+1) to 
(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.94-1 : Additional Protocol Configuration Options 



Octets (5 to m) of the Additional Protocol Configuration Options IE are encoded as specified in 3GPP TS 29.275 [26]. 
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8.95 Absolute Time of MBMS Data Transfer 

The Absolute Time of MBMS Data Transfer indicates the absolute time of the actual start, update or stop of the MBMS 
data transfer to ensure a synchronized session control and facilitate a graceful reallocation of resources for the MBSFN 
(MBMS Single Frequency Network) when needed for E-UTRAN access. 

It is coded as shown in figure 8.95-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 64 (decimal) 




2 to 3 


Length = n 




4 


Spare instance 




5 to 12 


Absolute Time of MBMS Data Transfer value part 




13to(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.95-1 : Absolute Time of MBMS Data Transfer 



Octets 5 to 12 are coded as the time in seconds relative to 00:00:00 on 1 January 1900 (calculated as continuous time 
without leap seconds and traceable to a common time reference) where binary encoding of the integer part is in the 32 
most significant bits and binary encoding of the fraction part in the 32 least significant bits. The fraction part is 
expressed with a granularity of 1 /2**32 second. 

8.96 H(e)NB Information Reporting 

H(e)NB number Information Reporting is coded as depicted in Figure 8.96-1. 

Bits 

Octets 8 7 6 5 4 3 2 1 

1 I Type = 1 65 I 
2 to 3 Length = n 

4 Spare | Instance 

5 Spare | FTI 

6 to (n+4) I These octet(s) is/are present only If explicitly specified | 

Figure 8.96-1 : l-l(e)NB Information Reporting 

The following bits within Octet 5 shall indicate: 

• Bit 1 - FTI: When set to "1", shall indicate to start reporting H(e)NB local IP address and UDP port number 
information change when the UE moves from (e)NB to H(e)NB, from H(e)NB to another H(e)NB with a fixed 
network backhaul change, or from H(e)NB to (e)NB. 

The bit 1 shall be set to to stop reporting H(e)NB local IP address and UDP port number information change. 

8.97 IPv4 Configuration Parameters (IP4CP) 

The IPv4 Configuration Parameters (IP4CP) is coded as depicted in Figure 8.97-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 66 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Subnet Prefix Length 




6 to 9 


IPv4 Default Router Address 




10 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.X-1: IPv4 Configuration Parameters (IP4CP) 
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8.98 Change to Report Flags 

Change to Report Flags IE is coded as depicted in Figure 8.x-l . 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 67 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare |TZCR|SNCR 




6 to (n+4) 


These octet(s) Is/are present only if explicitly specified 





Figure 8.98-1 : Change to Report Flags 



For each message the applicable flags of the Change to Report Flags IE shall be clearly specified in the individual 
message sub clause. The remaining flags of the Change to Report Flags IE not so indicated shall be discarded by the 
receiver. 

The receiver shall consider the value of the applicable flags as "0", if the Change to Report Flags IE is applicable for the 

message but not included in the message by the sender. 

The following bits within Octet 5 shall indicate: 

- Bit 8 to 3 - Spare, for future use and set to zero. 

Bit 2 - TZCR (Time Zone Change to Report): When set to 1, this bit indicates that a UE Time Zone change still 
needs to be reported to the SGW/PGW. 

- Bit 1 - SNCR (Serving Network Change to Report): When set to 1, this bit indicates that a Serving Network 
change still need to be reported to the SGW/PGW. 

8.99 Action Indication 

Action Indication is coded as depicted in Figure 8.99-1. 





Bits 


Octets 


8 7 6 5 4 3 2 1 


1 


Type = 1 68 (decimal) 




2 to 3 


Length = n 




4 


Spare Instance 




5 


Spare Indication 




6 to (n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.99-1 : Action Indication 



Table 8.99-1 : Indication 



Indication 


Values (Decimal) 


No Action 





Deactivation Indication 


1 


Paging indication 


2 


<spare> 


3to7 



If "deactivation indication" is set, it indicates that the receiving entity shall deactivate ISR and remove the UE resource 
locally as specified in 3GPP TS 23.007 [171 subclause 27.3.1.2. 

If "paging indication" is set, it indicates that the receiving entity shall page the IDLE state UE as specified in 3GPP TS 
23.007 L17J subclause 27.3.2.2. 

8.100 TWAN Identifier 

The TWAN Identifier is used for reporting UE location in a Trusted WLAN Access Network (TWAN) in order to 
provide charging information. See 3GPP TS 23.402 [45]. 
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Bits 






Dot Ate 


8 7 6 5 4 3 


2 


1 


1 


Type = 1 69 (decimal) 




^ 10 O 


Length = n 




4 


Spare Instance 




5 


Spare 


BSSI 
Dl 


SSIDI 




a to (a+5) 


BSSID 




k 


SSID Length 




(k+1) to m 


SSID 




(m+1) to 
(n+4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.100-1: TWAN identifier 



The BSSID and SSID shall be encoded as described in IEEE Std 802.11-2012 [52]. 

The BSSIDI flag in octet 5 indicates whether the BSSID in octets 'a' to (a+5) shall be present. If BSSIDI is set to T, 
then the BSSID shall be present. If BSSIDI is set to '0', then the BSSID shall not be present. 

The SSIDI flag in octet 5 indicates whether the SSID Length in octet 'k' and the SSID in octets (k+1) to 'm' shall be 
present. If SSIDI is '1', then these two fields shall be present. If SSIDI is '0', then these two fields shall not be present. 

The SSID Length in octet 'k' indicates the length of the SSID field. The SSID, if present, shall have a maximum length 
of 32 octets. 



9 Security 

GTPv2-C communications shall be protected according to security mechanisms defined in 3GPP TS 33.401 [12]. 



10 IP - The Networking Technology used by GTP 

10.1 IP Version 

GTPv2 entities shall support both versions of the Internet Protocol, version 4 (IPv4) as defined by IETF RFC 791 [6], 
and version 6 (IPv6) as defined by IETF RFC 2460 [16]. 

10.2 IP Fragmentation 

It is specified here how the fragmentation mechanism shall work with GTP-C. 
Fragmentation should be avoided if possible. Examples of fragmentation drawbacks are: 

- Fragmentation is inefficient, since the complete IP header is dupUcated in each fragment. 

- If one fragment is lost, the complete packet has to be discarded. The reason is that no selective retransmission of 

fragments is possible. 

Path MTU discovery should be used, especially if GTPv2-C message is encapsulated with IPv6 header. The application 
should find out the path MTU, and thereby utilise more efficient fragmentation mechanisms. 
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1 1 Notification of supported features between peer 
GTP-C entities 

11.1 General 

11.1.1 Introduction 

New functionality, i.e. functionality beyond the Rel-9 standard, which can not be specified without backward 
incompatible changes (e.g. requiring support of a new message or a specific receiver node's behaviour) should be 
introduced as a feature, see subclause 11.1.2. 

A GTP-C entity should verify that a backward incompatible feature is supported by its peer GTP entities before starting 
to use it. 

NOTE: GTPv2 does not support a Comprehension Required mechanism allowing a sender to force the receiver to 
support comprehension of some specific lEs as a precondition to process a backward incompatible 
message. 

Features may be generic node capabilities supported homogeneously for all GTP tunnels, UEs and PDN cormections. 
Such features are referred in this specification as "Node Features". They are signalled with the granularity of a node on 
all GTPv2 interfaces (i.e. SI 1, S4, S5, S8, SIO, S3, S16, Sv, SlOl, Sm, Sn, S2a, S2b). A GTP-C entity may discover the 
features supported by a peer GTP-C entity with which it is in direct contact as specified in subclause 11.2.1. 

11.1.2 Defining a feature 

A feature is a fimction extending the base GTPv2 functionality that has a significant meaning to the operation of 
GTPv2, i.e. a single new parameter without a substantial meaning to the functionality of the GTPv2 endpoints should 
not be defined to be a new feature. 

A functionality requiring the definition of a new GTPv2 message or extending the use of an existing message over a 
new interface should be defined as a feature. 

NOTE: Features are ultimately defined on a case-by-case basis on the merits of defining an extension as a feature. 

Features should be defined so that they are independent from each other. A GTP-C entity may support the same feature 
over different interfaces, e.g. an SGW may support a feature over both SI 1 and S4 interface, however support of a 
feature on a given interface shall not depend on the support of the same or another feature on another interface. 

1 1 .2 Dynamic discovery of supported features 

11.2.1 General 

A node supporting at least one feature defined in the Node Features IE shall support dynamic discovery of supported 
features as specified in the following subclauses. 

1 1 .2.2 Features supported by direct peer GTP-C entities 

A node shall signal to a direct peer node the list of features it supports by sending the Sending Node Features IE in the 
Echo Request and Echo Response messages. 

An exception to this is where the sending node does not support or use any features towards the peer node and is not 
prepared to accept a message which is constructed by making use of any features. 

The peer receiving the Sending Node Features IE shall store the hst of features supported by the sending node per IP 
address and only update this list based on the Sending Node Features IE in the Echo Request and Echo Response 
messages, and it shall only use common supported features to initiate subsequent GTPv2 messages towards this IP 
address. 
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Annex A (Informative): 

Backward Compatibility Guidelines for Information Elements 

In order to preserve backward compatibility, the following rules should apply when adding or modifying information 
elements for existing messages. 

- No new mandatory (M) information elements should be added. 

- No new conditional (C) information elements should be added. 

- Any new lEs should be either: 

optional (O), having no conditions on their presence, or 

conditional-optional (CO), having conditions that should apply only to the sender and not to the receiver. 

Such conditions should be worded generally as follows: "This IE shall be sent over the xxx interface 
<condition>. The receiving entity need not check the lE's presence." 

If any new conditions are added to a previously specified conditional (C) information element, these new 
conditions should apply only to the sender and not to the receiver. 

Such additional conditions should be worded gener£illy as follows: "This IE shall be sent over the xxx interface 
<condition>. For this optional condition, the receiving entity need not check the lE's presence." 

Existing conditions for such conditional (C) lEs should be treated as before, and the presence of the lEs should 
remain conditional (C). 
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Annex B (Informative): 

Transparent copying of RANAP/S1 AP lEs into GTP lEs 
B.1 General 

This annex provides details on how a GTPv2 entity transparently copies information received from RANAP or SlAP 
into GTPv2 IE or IE field. 

RANAP and SlAP ASN.l encoding details in this annex are informative. The reference specifications are 3GPP TS 
25.413 [33] and 3GPPTS 36.413 [10] respectively. 

The respective RANAP/SIAP Information Elements are transported on the lu/Sl interface within a "protocol-IE 
container" which is composed of: 

an Information Element Identity (referred to below as "IE-ID"), 

an indication how the receiver shall react if the Information Element is not comprehended (referred to below as 
"criticality"), 

and an "open type field" which consists of a length indication ("OT-LI") and the Information Element itself 
(referred to below as "IE"). 

RANAP/SIAP PDUs and the contained lEs are defined by means of ASN.l, the specified encoding is PER (packed 
encoding rule). Octet aligned variant: 

PER minimises the information sent on the respective interface to the absolute minimum; 

Hence, type definitions of fixed length are encoded without any type or length indication, only type definitions 
of variable length contain a length indication, e.g. 

an OCTET STRING with indefinite length would need to contain a length indication (referred to below as 
"OCT-LI") followed by the actual octets (referred to below as "octets"); 

a SEQUENCE neither contains a type, nor a length-indication. Only in case of optional elements it contains a 
kind of bit string with each position of this bitstring indicating the presence of an OPTIONAL element (an 
encoded SEQUENCE type is referred to below as "sequence"). 

B.2 Handover/Relocation related generic transparent 
Containers over RANAP, S1-AP and GTP 

Handover/Relocation related generic transparent containers are defined in 3GPP TS 25.413 [33] and 3GPP TS 36.413 
[10] ("Source to Target Transparent Container" IE and "Target to Source Transparent Container" IE) to carry UTRAN, 
E-UTRAN or GERAN specific information via CN interfaces in a RAT-agnostic way. 

The encoding of these handover/relocation related generic transparent containers is different in RANAP and Sl-AP. See 
3GPP TS 36.413 [10] Annex C. The difference is that the "Source to Target Transparent Container" IE and "Target to 
Source Transparent Container" IE are ASN.l encoded over RANAP as "lE-IDIIcriticalityllOT-LIIIoctets" (i.e. one length 
field only for the open type field) and over SlAP as "lE-IDIIcriticaHtyllOT-LIIIOCT-LIIIoctets" (i.e. with 2 length fields, 
one for the open type field ("OT-LI"), one for the octet string encoding ("OCT-LI")), while "octets" contain the actual 
RAT specific handover/relocation information. 

This gives the following chain of encodings (represented in the notation introduced in the Notes above) end-to-end. 
LTE to LTE 
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eNB 



S-MME 



Handover Required 



'SourceToTargetTransparent Container" transported via an 
IE container == (lE-IDIcriticalityllOT-LIIlIE) 
IE = OCT-LIIIoctets 

octets == sequence ="Source eNB to Target eNB 
Transparent Container" 



T-MME 



"F-Container field" 

► 

contains "sequence" only 



eNB 



Handover Request 



"SourceToTargetTransparent Container" transpc 
IE container == (lE-IDIcriticalityllOT-LIIlIE) 
IE == OCT-LIIIoctets 
octets ~ sequence ~ "Source eNB to Target e >JB 
Transparent Container" 



rted via an 



Figure B.2-1 : LTE to LTE - Encoding of Generic Transparent Containers 

In the case of LTE-LTE handover, the "octets" contain the "Source eNB to Target eNB Transparent Container" (defined 
as an ASN.l SEQUENCE in 3GPP TS 36.413[10]). 

The source MME, after decoding the HO REQUIRED message of SlAP, passes transparently the "sequence" to the 
target MME. 

The target MME encodes similarly at target side with the same definitions: it feeds the received "sequence" into the 
SlAP ASN.l encoder in order to encode the HO REQUEST message towards the target eNB. The "sequence" is then 
extracted from the SlAP ASN.l of eNB and given to application part of eNB. 



LTE to 3G 



eNB 



S-MME 



Handover Required 



'SourceToTargetTransparent Container" transported via an 
IE container == (lE-IDIcriticaUtyllOT-LIIlIE) 
IE == OCT-LIIIoctets 

octets == sequence ="Source RNC to Target RNC 
Transparent Container" 



SGSN 



"F-Container field" 

► 

contains "sequence" only 



RNC 



Relocation Request 



"SourceToTargetTransparent Container" transported via an 
IE container = {lE-IDIcriticalityllOT-LIIlIE) 
IE ~ sequence == "Source RNC to Target RNC 
Transparent Container" 



Figure B.2-2: LTE to 3G - Encoding of Generic Transparent Containers 

At source side, the same encoding is done but for LTE to 3G handover, this time the "octets" on the line is the "Source 
RNC to Target RNC Transparent Container" (encoded according to the target system RANAP i.e. as an ASN. 1 
SEQUENCE in 3GPP TS 25.413 [33]). 

Again the source MME passes transparently the "sequence" to the target MME i.e. the "Source RNC to Target RNC 
Transparent Container". 

At the target side, the RANAP RELOCATION REQUEST message was not upgraded: the "sequence" received from 
the Gn or S3 interface ("Source RNC to Target RNC Transparent Container") is not encoded as an OCTET STRING as 
on SI, but directly represent the "Source To Target Transparent Container" within the RANAP:REL0CAT10N 
REQUEST message, which in case of inter-RAT handover to 3G represent the "Source RNC to Target RNC 
Transparent Container", transported on the lu interface as the "IE" part of the "IE container". There is no additional 
length field added as on the SI interface ("OCT-LI"). 

The target side remains therefore fully backwards compatible with UMTS release 7. 
3G to LTE 
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RNC R8 



SGSN (R7) 



Relocation Required 



"SourceToTargetTransparent Container" transported via an 
IE container == (lE-IDIcriticalityllOT-LIIlIE) 
IE == sequence =="Source eNB to Target eNB Transparent 
Container" 



T-MME 



"F-Container field" 

► 

contains "sequence" only 



eNB 



Handover Request 



"SourceToTargetTransparent Container" transported 'ia an 
IE container == (lE-IDIcriticalityllOT-LIIlIE) 
IE == OCT-LIIIoctets 

octets ~ sequence =="Source eNB to Target eNB 
Transparent Container" 



Figure B.2-3: 3G to LTE - Encoding of Generic Transparent Containers 

The RELOCATION REQUIRED message was upgraded from release 8 onwards renaming the previously contained 
"Source RNC to Target RNC Transparent Container" to "Source to Target Transparent Container", being able to 
transport also a "Source eNB to Target eNB Transparent Container". 

Despite being defined as an octet string, in order to not impact the R7 SGSN, the octet string was specified as "to be 
replaced" by either the UTRAN or E-UTRAN specific container. This fact is explained e.g. within the NOTE in the 
ASN.l of 3GPP TS 25.413 [33] ], as shown in this excerpt: 

Source-ToTarget-TransparentContainer ::= OCTET STRING 

-- This IE is a transparent container, the IE shall be encoded not as an OCTET STRING but according 
to the type specifications of the target system. 

-- Note: In the current version of this specification, this IE may either carry the Source RNC to 
-- Target RNC Transparent Container or the Source eNB to Target eNB Transparent Container IE as 
-- defined in [49] 

By so doing, the Release 7 source SGSN receives only one length field (the "OT-Ll") instead of two (the "OT-LI and 
the "OCT-Ll") as if it would receive an "Source RNC to Target RNC Transparent Container" from a Release 7 RNC, 
ensuring fully Release 7 backwards compatibihty as requested by 3GPP TS 23.401 [3] Aimex D. This is illustrated in 
Figure B.1-3 above. 

As explained above, this Release 7 backwards compatibility constraint only applies to RANAP to cope with Release 7 
SGSN nodes and does NOT apply to LTE. This is why the note is NOT present in the ASN. 1 of 3GPP TS 36.413 [10] 
for LTE i.e. the SlAP octet string does not need "to be replaced". 

Then "sequence" is passed transparently to the target MME. The target MME encodes the "sequence" within an OCTET 
STRING resulting in two length fields as expected by target eNB ASN.l SlAP decoder. 



B.3 Other RANAP and S1 -AP I Es 

When transparently copying a RANAP/SIAP IE, other than the handover/relocation related generic transparent 
containers (see Annex B.l) into GTP IE, or GTP IE field the following appUes: 

a transparent copy of a RANAP/SIAP IE, which is transported on the lu/Sl interface within a "protocol-IE 
container", neither includes the Information Element Identity ("IE-ID") nor the "criticality" nor the open type 
field related length indication ("OT-LI"), but only the Information Element itself ( "IE"). 

"IE" refers to all parts of the encoded type of the Information Element, i.e. including also any related length 
indication (in case of types with variable length) and preamble (see ITU-T X.691 [49] for the definition of the 
term "preamble"). 
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Annex C (Normative): 

MME/S4-SGSN mapping table between S1 1/S4 and NAS 
Cause values 

The MME/S4-SGSN initiates session management requests towards the SGW and PGW. If this operation is not 
successful, there are several possible cause codes, which need to be mapped to appropriate cause codes over NAS to the 
UE. 

The MME/S4-SGSN should map these cause codes as defined in tables C.l to C.4 unless specified otherwise in the 
tables. 
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Table C.I : Mapping from S11/S4 to NAS Cause values - Rejection indication from SGW 



Reject indication from SGW to 
MI\/IE/S4-SGSN 
over S11/S4 


NAS ESM Cause to UE 

(NOTE 1 , NOTE 2, NOTE 3) 


SM Cause to UE 

(NOTE 1 , NOTE 2, NOTE 3) 


#64 "Context not found" (during 
UE initiated PDN connectivity 
request for non-3GPP to 3GPP 
handover procedure) 


#54 "PDN connection does not exist" 


#30 "Activation rejected by GGSN, 

Serving GW or PDN GW" 

#31 "Activation rejected, unspecified" 


#64 "Context not found" (during all 
other procedures) 


#30 "Request rejected by Serving GW 
or PDN GW"#38 "Network failure" 
#43 "Invalid EPS bearer identity" 


#30 "Activation rejected by GGSN, 

Serving GW or PDN GW" 

#38 "Network failure" 

#43 "Unknown PDP Context" 


#65 Invalid Message Format 


#30 "Request rejected by Serving GW 

or PDN GW 

#38 "Network failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW 
#38 "Network failure" 


#66 "Version not supported by next 
peer" 


#30 "Request rejected by Serving GW 

or PDN GW 

#38 "Network failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW 
#38 "Network failure" 


#67 "Invalid length" 


#30 "Request rejected by Serving GW 
or PDN GW 

#38 "Network failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW 
#38 "Network failure" 


#68 "Service not supported" 


#32 "Service option not supported" 


#32 "Service option not supported" 


#69 "Mandatory IE incorrect" 


#30 "Request rejected by Serving GW 

or PDN GW" 

#38 "Network failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW" 
#38 "Network failure" 


#70 "Mandatory IE missing" 


#30 "Request rejected by Serving GW 

or PDN GW" 

#38 "Network failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW" 
#38 "Network failure" 


#72 "System Failure" 


#34 "Service option temporarily out of 
order" 

#38 "Network Failure" 

#30 Request rejected by Serving GW 

or PDN GW 


#34 "Service option temporarily out of 
order" 

#38 "Network failure" 

1 1 rtllAx' J." L II K 1 

#30 Activation rejected by GGSN, 
Serving GW or PDN GW 


#73 "No Resources available" 


#34 "Service option temporarily out of 
order" 

#26 "Insufficient resources" 


#34 "Service option temporarily out of 
order" 

#26 "Insufficient resources" 


#76 "Semantic errors in packet 
filter(s)" 


#44 "Semantic errors in packet filter(s)" 


#44 "Semantic errors in packet filter(s)" 


#77 Syntactic errors in packet 
filter(s)" 


#45 Syntactical error in packet filter(s) 


II A ^ II ^ X X' 1 1 xX'lx / 

#45 Syntactical error in packet filter(s) 


#78 Missing or unknown APN 


# 27 Missing or unknown APN 


II iih ji" ' 1 A III 

# 27 Missing or unknown APN 


#80 "GRE key not found" 


#30 "Request rejected by Serving GW 

or PDN GW 

#38 "Network Failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW 
#38 "Network failure" 


#83 "Preferred PDN type not 
supported" 


#32 "Service option not supported" 
#50 PDN type IPv4 only allowed 
#51 "PDN type IPv6 only allowed" 


#32 "Service option not supported" 

I J 1" /-\ If i— \ 1-^ 1— fc I 1 A \ II III 

#50 PDP type IPv4 only allowed 
#51 "PDP type IPv6 only allowed" 


#84 "All dynamic addresses are 
occupied" 


#26 "Insufficient resources" 


#26 "Insufficient resources" 


#85 "UE context without TFT 
already activated" 


NA 


#46 "PDP context without TFT already 
activated" 


#86 "Protocol type not supported" 


#30 "Request rejected by Serving GW 

or PDN GW" 

#38 Network Failure 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW" 

I \ *^ Mh 1 X 1 X '1 II 

#38 Network failure 


#89 "Service denied" 


#30 "Request rejected by Serving GW 
or PDN GW" 

#31 "Request rejected, unspecified" 
#38 "Network failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW" 
#31 "Activation rejected, unspecified" 
#38 "Network failure" 


#91 "No memory available" 


#34 "Service option temporarily out of 
order" 

#26 "Insufficient resources" 


#34 "Service option temporarily out of 
order" 

#26 "Insufficient resources" 


#92 "User authentication failed" 


#29 "User authentication failed" 


#29 "User authentication failed" 


#93 "APN access denied - no 
subscription" 


#33 "Requested service option not 
subscribed" 

# 27 "Missing or unknown APN" 


#33 "Requested service option not 
subscribed" 

# 27 "Missing or unknown APN" 
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#94 Request rejected (reason not 
specified)" 


#30 Request rejected by Serving GW 

or PDN GW" 

#38 "Network Failure" 


Jl rtllJlx' X' X II K 1 

#30 Activation rejected by GGSN, 
Serving GW or PDN GW" 
#38 "Network failure" 


11/** ^ 11/^ X' xi "T" A 

#97 Semantic error in tlie TAD 


J I A J M/^ X' Xl — n 1 

#41 Semantic error in the TFT 


1 1 A A \\f^ X' xl 1" 1 1 

#41 Semantic error in the TFT 


operation" 


operation" 


operation" 


#98 "Syntactic error in tlie TAD 
operation" 


#42 "Syntactical error in the TFT 
operation" 


#42 "Syntactical error in the TFT 
operation" 


#100 "Remote peer not 
responding" 


#34 "Service option temporarily out of 
order" 

#38 "Network Failure" 


#34 "Service option temporarily out of 
order" 

#38 "Network failure" 


#101 "Collision with network 


#56 "Collision with network initiated 


#56 "Collision with network initiated 


initiated request" 


request" 


request" 


#103 "Conditional IE missing" 


#30 "Request rejected by Serving GW 

or PDN GW" 

#38 Network Failure 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW" 

Jl IIK 1 X 1 X '1 II 

#38 Network failure 


#104 "APN Restriction type 


#1 1 2 "APN restriction value 


#112 "APN restriction value 


Incompatible with currently active 
PDN connection" 


incompatible with active EPS bearer 
context" 


incompatible with active PDP context" 


#107 "Invalid reply from remote 
peer" 


#30 "Request rejected by Serving GW 
or PDN GW" 

#31 "Request rejected, unspecified" 


#30 "Activation rejected by GGSN, 

Serving GW or PDN GW" 

#31 "Activation rejected, unspecified" 


#112 "Request rejected for a 
PMIPv6 reason (see 3GPP TS 
29.275 [26]). 


#30 "Request rejected by Serving GW 

or PDN GW" 

#38 "Network Failure" 


#30 "Activation rejected by GGSN, 
Serving GW or PDN GW" 
#38 "Network failure" 


#1 1 3 "APN Congestion" 


#26 "Insufficient resources" 


#26 "Insufficient resources" 


#114 "Bearer handling not 
supported" 


#60 "Bearer handling not supported" 


#60 "Bearer handling not supported" 


#116 "Multiple PDN connections 
for a given APN not allowed" 


#55 "Multiple PDN connections for a 
given APN not allowed" 


#30 "Activation rejected by GGSN, 

Serving GW or PDN GW" 

#31 "Activation rejected, unspecified" 


NOTE 1 : See 3GPP TS 24.301 [23 


and 3GPP TS 24.008 [5] for NAS ESM and SM causes respectively. 


NOTE 2: The l\/IME/S4-SGSN may for certain OTP cause codes trigger a new OTP procedure instead of rejecting the 
NAS request. 

NOTE 3: When multiple NAS Cause values are defined for a given GTP cause value, any of those NAS Cause values 


may be sent to the UE based on implementation choice. 





Table C.2: Mapping from S11/S4 to NAS Cause values - Acceptance indication from SGW 



Acceptance indication from SGW to 
MME/S4-SGN 
over S11/S4 


NAS ESM Cause to UE 


SM Cause to UE 


#18 "New PDN type due to network 
preference" 


#50 "PDN type IPv4 only allowed" 
#51 "PDN type IPv6 only allowed" 
(NOTE 1) 


#50 "PDP type IPv4 only allowed" 
#51 "PDP type IPv6 only allowed" 
(NOTE 1) 


#19 "New PDN type due to single 
address bearer only" 


#52 "single address bearers only 
allowed" 


#52 "single address bearers only 
allowed" 


NOTE 1 : The actual NAS cause sent to the UE depends on the allocated IP address type. 


Table C.3: lUlapping from S11/S4 to NAS Cause values - Indication in request from SGW 


Indication in a request / initial 
message from SGW to MME/S4- 
SGSN over S11/S4 


NAS ESM Cause to UE 


SM Cause to UE 


#8 "Reactivation Requested" 
(NOTE 1) 


Shall be mapped to: 

#39 "Reactivation requested" in the 

NAS bearer context deactivation 

procedure. 

For the last PDN connection in E- 
UTRAN, "Reactivation requested" 
shall be mapped to "re-attach 
required" in the NAS detach type IE. 


Shall be mapped to: 

#39 "Reactivation requested" in the 

NAS bearer context deactivation 

procedure. 


#9 "PDN reconnection to this APN 

disallowed" 

(NOTE 1) 


Implementation specific NAS cause 
value indicating to the UE that the 
APN is not currently available. 


Implementation specific NAS cause 
value indicating to the UE that the 
APN is not currently available. 
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For the last PDN connection, MAS 
detach type IE should be set to "re- 
attach not required". 




NOTE 1 : In Delete Bearer Request during the PGW initiated PDN connection deactivation procedure. 



Table C.4: Mapping from NAS to S11/S4 Cause values - Rejection indication from MME/S4-SGSN 



NAS ESM Cause from UE 

(NOTE 1) 


SM Cause from UE 

(NOTE 1) 


Reject indication from MME/S4- 
SGSN to SGW 
over S11/S4 

(NOTE 2) 


#26 "Insufficient Resources" 


#26 "Insufficient Resources" 


#73 "No Resources available" 
#88 "UE refuses" 


#31 "Request rejected, unspecified" 


#31 "Activation rejected, unspecified" 


#94 "Request rejected" 
#88 "UE refuses" 


#41 "Semantic error in the TFT 

operation" 


#41 "Semantic error in the TFT 

operation" 


#74 "Semantic error in the TFT 

operation" 


#42 "Syntactical error in the TFT 
operation" 


#42 "Syntactical error in the TFT 
operation" 


#75 "Syntactical error in the TFT 
operation" 


#43 "Invalid EPS bearer identity" 


#43 "Unknown POP Context" 


#64 "Context not found" 
#88 "UE refuses" 


#44 "Semantic errors in packet 

filter(s)" 


#44 "Semantic errors in packet 

filter(s)" 


#76 "Semantic errors in packet 

filter(s)" 


#45 "Syntactical error in packet 
filter(s)" 


#45 "Syntactical error in packet 
filter(s)" 


#77 "Syntactical error in packet 
filter(s)" 


#47 "PTI mismatch" 


NA 


#94 "Request rejected" 

#88 "UE refuses" 


NA 


#48 "Request rejected. Bearer Control 
Mode violation" 


#94 "Request rejected" 
#88 "UE refuses" 


#81 "Invalid PTI value" 


NA 


#94 "Request rejected" 
#88 "UE refuses" 


NOTE 1 : See 3GPP TS 24.301 [23] and 3GPP TS 24.008 [5] for NAS ESM and SM causes respectively. 
NOTE 2: When multiple GTPv2 Cause values are defined for a given NAS Cause value, any of those GTPv2 Cause 
values may be sent to the SGW based on implementation choice. 
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PDN Connection for Subscription Data 


9.3.0 


9.4.0 






CP-1 00444 


C4-1 02329 


0748 


1 


A 


Change 






2010-09 


CT#49 


CP-1 00444 


C4-1 02331 


0750 


1 


A 


E-UTRAN to HRPD handover 


9.3.0 


9.4.0 


201 0-09 


CT#49 


CP-1 00451 


C4-1 02208 


0751 




F 


Correcting type value of the MBMS Session 
Start Response message 


9.3.0 


9.4.0 


2010-09 


CT#49 


CP-1 00451 


C4-1 02229 


0754 




F 


GTP protocol errors 


9.3.0 


9.4.0 


201 0-09 


CT#49 












Essential Clarification in Forward Relocation 


9.3.0 


9.4.0 






CP-1 00451 


C4-1 02357 


0755 


1 


F 


Response message 






2010-09 


CT#49 


CP-1 00469 


C4-1 02302 


0662 


4 


B 


New Modify Access Bearers procedure 


9.4.0 


10.0.0 


2010-09 


CT#49 


CP-1 00469 


C4-1 02382 


0698 


6 


B 


Notification of supported features between 
peer GTP-C entities 


9.4.0 


10.0.0 


2010-09 


CT#49 


CP-1 00469 


C4-1 02300 


0734 


1 


B 


Length of IPv6 Prefix 


9.4.0 


10.0.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 02766 


0758 


1 


F 


01 flag in Delete Session Request alignment 
with stage 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 02836 


0762 


3 


B 


ISR in Delete Bearer Request 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 03277 


0787 


4 


B 


PGW Restart Notification 


10.0.0 


10.1.0 


2010-12 


CT#50 












Feature definition for the Modify Access 


10.0.0 


10.1.0 






CP-1 00695 


C4-102912 


0798 


2 


F 


Bearers procedure 






2010-12 


CT#50 


CP-1 00695 


C4-1 02771 


0799 


1 


F 


Modify Access Bearers procedure during Inter- 
MME Intra-SGW TAU 


10.0.0 


10.1.0 
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Date 


TSG# 




im||||)oc 


CR 


Rev 


Cat 


Subject/Comment 


Old 


New 


2010-12 


CT#50 


CP-1 00695 


C4-1 03274 


0812 




F 


Clarifications to Failure Indication type of 
messages 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 03362 


0817 




B 


EPS Bearer ID in Downlink Data Notification 
message 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 03276 


0818 


1 


F 


Clarifying possible cause value sets 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4- 103343 


0823 




F 


SGSN Failure handling 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 03283 


0835 


— J— 


F 


Handover Indication 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00695 


C4-1 03288 


0842 




F 


Cause values for Delete Bearer Request 


10.0.0 


10.1.0 


2010-12 


CT#50 


GP-1 00688 


C4-103315 


0848 




B 


MME/SGSN overload control by throttling of 
DL low priority traffic 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02779 


0773 


— J— 


A 


Suspend and Resume procedure 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02781 


0775 




A 


Range for BSSGP Cause 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02783 


0777 


1 


A 


RAT Type in the Modify Bearer Request 

message 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-102514 


0781 




A 


ISR for SGW 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02787 


0783 


1 


A 


ISR in the Detach procedure 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02789 


0789 


1 


A 


Missing Cause Code mapping for IRAT 
Handover between GERAN and EUTRAN 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02556 


0794 




A 


Voice bearer flag 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02794 


0801 




A 


MBMS corrections 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 03238 


0821 




A 


CSG Reporting 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 02938 


0825 




A 


Target Identification 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 03322 


0830 




A 


Reporting UE Time Zone changes 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4- 103249 


0838 




A 


Essential correction for UE Timezone reporting 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00675 


C4-1 03331 


0846 




A 


ISR activated flag 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00672 


C4-1 03294 


0851 




F 


Determination of type of source node during 

TAU/RAU 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00674 


C4-1 02775 


0765 




A 


Essential correction to Create Indirect Data 
Forwarding Tunnel Response 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00686 


C4-1 02796 


0767 




B 


GTP-C Information Elements for GTP based 
S2b interface 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00686 


C4-1 02539 


0786 


- 


B 


Delete PDN Connection Set 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00686 


C4-1 02560 


0796 




B 


Addition of GTP over S2b to clauses 1 to 6 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00686 


C4-103135 


0797 


3 


B 


Create Session Request/Response & Create 
Bearer Request/Response 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00686 


04-1 02599 


0802 




B 


Dplptp RpQciInn and Rparpr mpQQanpQ 


10.0.0 


1 0.1 .0 


2010-12 


CT#50 


CP-1 00686 


C4-1 02629 


0804 




B 


KyinHif\/ Rpnrpr O.nmnnnnH/Psilli irp InHlr'sitinn 

IVIWVJIiy LJC'CtlC'l v^UI 1 1 1 1 Idl 1 ullLIIC II lUI^/ClllUI 1 

and Update Bearer Req/Rsp 


10.0.0 


1 0.1 .0 


2010-12 


CT#50 


CP-1 00686 


C4-1 02650 


0807 




B 


Trace Session Activation/Deactivation for 

GTP-S2b 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00686 


C4-1 03300 


0839 


1 


B 


Handling of Create Session Request message 
on header TEID = 


10.0.0 


10.1.0 


2010-12 


CT#50 












Downlink data notification information for MPS 


10.0.0 


10.1.0 






CP-1 00687 


C4-1 02928 


0769 


2 


B 


services 






2010-12 


CT#50 


CP-1 00667 


C4-1 02970 


0828 


_ 


A 


UE Time Zone adjustments 


10.0.0 


10.1.0 


2010-12 


CT#50 


CP-1 00669 


C4-1 03340 


0816 


2 


F 


Essential alignment with PMIP spec 


10.0.0 


10.1.0 


2011-03 


CT#51 


CP-110064 


C4-110875 


0921 


1 


B 


Data Delay Notification 


10.1.0 


10.2.0 


201 1-03 


CT#51 


CP-1 10064 


C4-1 10585 


0916 




F 


Clean up with GTP-C Information Elements 


10.1.0 


10.2.0 


2011 -03 


CT#51 












Inclusion of Node Type in DDN Failure 


10.1.0 


10.2.0 






CP-110064 


C4-1 10831 


0911 


1 


F 


Indication when the ISR is active 






2011-03 


CT#51 


CP-1 10064 


C4-1 10828 


0897 


1 


F 


Create Session Response 


10.1 .0 


10.2.0 


2011-03 


CT#51 


CP-1 10064 


C4-1 10479 


0896 




F 


UE Network Capability IE 


10.1 .0 


10.2.0 


201 1-03 


CT#51 


CP-110064 


C4-1 10955 


0895 


2 


F 


ArJHInn "Initial" "Trinnprprt" and "Initial nr 

r^uui 11^ iiiiLidi , iii^^d uiiu iiiilicii \J\ 

triggered by a Command" attributes to the 
messages in table 6.1 


10.1 .0 


1 0.2.0 


2011-03 


CT#51 


CP-110064 


C4-1 10826 


0894 


1 


D 


Adding a separate subclause for TEID=0 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110064 


C4-1 10825 


0893 


1 


F 


Removing optional Cause IE from Echo 
Response 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110064 


C4-1 10830 


0875 


2 


F 


RAT type clarification for S4-SGSN 


10.1.0 


10.2.0 


2011-03 


CT#51 












Essential correction to the table NOTE for the 


10.1.0 


10.2.0 






CP-110064 


C4-1 10331 


0874 


1 


F 


Create Session Response message 






2011-03 


CT#51 


CP-110064 


C4-1 10369 


0872 


1 


F 


Error Indication for SGW 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110064 


C4-1 10257 


0871 


1 


D 


Cleanup for GTPv2 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110064 


C4-1 10392 


0870 


2 


F 


RAT Type in Modify Access Bearers Request 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110064 


C4-110112 


0869 


_ 


F 


Bearer context in Modify Bearer Request 


10.1.0 


10.2.0 


2011-03 


CT#51 












SI -U eNodeB F-TEID IE in the Modify Access 


10.1.0 


10.2.0 






CP-110064 


C4-1 10062 


0860 




F 


Bearers Request 






2011-03 


CT#51 


CP-110064 


C4-1 10322 


0855 


1 


F 


Correction for VNSI 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-110064 


C4-1 10882 


0844 


6 


F 


Serving Network IE 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10061 


C4-1 10548 


0856 


2 


B 


APN based congestion control 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10061 


C4-1 10310 


0858 


1 


B 


Low access priority indicator 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10060 


C4-1 10348 


0859 


1 


B 


EBI and ARP lEs in Downlink Data Notification 


10.1.0 


10.2.0 
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Date 


TSG # 






CR 


Rev 


Cat 


Subject/Comment 


Old 


New 


2011-03 


CT#51 


CP-1 1 0049 


04-1 10994 


0918 


2 


A 


Protocol Configuration Options (POO) in 
Delete Bearer Response 


10.1.0 


10.2.0 


2011-03 


CT#51 












UE Time Zone condition Delete Session 


10.1.0 


10.2.0 






CP-1 10049 


C4-1 10889 


0901 


1 


A 


Request 






2011-03 


CT#51 


CP-1 10049 


C4-10971 


0889 


3 


A 


Subscribed UE-AMBR in mobility procedure 


10.1.0 


10.2.0 


20 11 -03 


CT#51 












Essential correction to the fallback to GTPvl 


10.1.0 


10.2.0 






CP-1 10049 


C4-1 10990 


0884 


5 


A 


feature 






201 1-03 


CT#51 


CP-1 10049 


C4-1 10333 


0881 


1 


A 


RAT Type in the Modify bearer recjuest 
message 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10049 


C4-110170 


0879 




A 


Missed procedures for the Delete Session 

Request and Response messages 


10.1.0 


10.2.0 


2011 -03 


CT#51 


CP-1 10049 


C4-1 10330 


0866 


1 


A 


Correction to passing of LDN 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 1 0049 


C4-1 10074 


0862 




A 


SI 03 resource release 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10049 


04-110186 


0886 




A 


Essential correction to the to GTPv2 cause 
table 


10.1.0 


10.2.0 


2011-03 


CT#51 












Essential correction to the encoding of Target 


10.1.0 


10.2.0 






CP-1 10042 


C4-1 10979 


0914 


1 


A 


RNC-ID 






2011-03 


CT#51 


CP-1 10056 


C4-111009 


0887 


5 


B 


Unsupported Bearer Handling for LlPA 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10083 


C4-1 10952 


0892 


3 


B 


Adding IMSI to DDN 


10.1.0 


10.2.0 


201 1-03 


CT#51 


CP-1 10053 


C4-1 10824 


0899 


1 


A 


Temporary Mobile Group Identity 


10.1.0 


10.2.0 


2011-03 


CT#51 


CP-1 10042 


04-110365 


0867 


1 


A 


Correcting IE Type for Bearer QoS IE from 
Variable to Extendable 


10.1.0 


10.2.0 


201 1-03 


CT#51 


CP-1 10266 


- 


0903 


2 


A 


1 IF Ximo 7nn& nnnHitinn in MnHifu R^nr^r 

\Jl 1 II 1 IC £—\JI IC t^UI lUlllUI 1 III IVIUUI 1 y UCQI CI 

Request 


1 0.1 .0 


10.2.0 


201 1-03 


CT#51 


CP-1 10059 


04-1 10583 


0915 




B 


^pr\/inn notwnrk in thp ("irpsito ^^QQinn 

OCI vll lU 1 IdWUI i\ II 1 LI IC wl CQLC OCOOIUI 1 

RGQUeSt m6SS3Q6 


1 0.1 .0 


10.2.0 


2011-03 


CT#51 


CP-1 1 0072 


04-110887 


0923 




B 


CS BIT to bG availabl6 for initial rnGSsago 


10.1.0 


10.2.0 


201 1-05 














FHitorial porrpptinn In ^pptinn 7 10 hpraii^p nf 

misimplGntation of CT#51 agrGGd CR C4- 
1 1 0990 


10.2.0 


1 0.2.1 


2011-06 


CT#52 


CP-1 10355 


04-111629 


0927 


2 


A 


Mapping of ASN.1/PER paranriGtGrs to GTPv2 
lEs 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10355 


04-111630 


0940 


3 


F 


Downlink Data Notification for S4 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10355 


04-111551 


0964 


1 


A 


IE TypG ExtGndabiG CorrGCtions 


10.2.1 


10.3.0 


2011-06 


CT#52 












Fix SRVCC rolatGd data transfor bGtwGon 


10.2.1 


10.3.0 






CP-1 10366 


04-1 1 1 596 


0930 


2 


A 


IVIIVlEs/SGSNs 






2011-06 


CT#52 












UE Time Zone IE in Delete Session Request 


10.2.1 


10.3.0 






CP-1 10366 


04-111529 


0932 


1 


A 


message 

3. 






2011-06 


CT#52 


CP-1 10366 


04-111409 


0943 


1 


A 


Higher bitrates than 16 Mbps flag 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10366 


04-111545 


0953 


1 


A 


Temporary Rejection Cause 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10366 


04-111556 


0958 


1 


A 


Cause IE in DDN message 


10.2.1 


10.3.0 


2011-06 


CT#52 












Alignment with stage 2 for EPC node restart 


10.2.1 


10.3.0 






CP-1 10378 


04-111656 


0928 


2 


B 


with active ISR 






2011-06 


CT#52 


CP-1 10374 


04-111434 


0924 


1 


F 


Setting a sequence number in a Command 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10374 


04-111487 


0941 


1 


F 


Clarification for Create Session Response 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10374 


04-111488 


0944 


2 


F 


Max MBR/APN-AMBR 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10374 


04-111613 


0947 


3 


F 


Inactive Emergency PDN Handling 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10374 


C4-1 11236 


0948 




B 


ARP supporting on M3 interface for MBMS 


10.2.1 


10.3.0 


201 1-06 


CT#52 


CP-1 10374 


C4-1 1 1237 


0949 




F 


Downlink Data Notification message 


10.2.1 


10.3.0 


201 1 


CT#52 


CP-1 10374 


04-111495 


0950 


1 


F 


Serving Networl^ 


10.2.1 


10.3.0 


2011-06 


CT#52 


CP-1 10374 


04-111593 


0956 


2 


F 


Serving Networl< IE in Modify Bearer Request 


10.2.1 


10.3.0 


201 1-06 


CT#52 


CP-1 10369 


04-111164 


0945 




B 


1 API Hiirinn 1 IF initintpH hpnrpr rpQniirrp 

allocation / modification procedures 


10.2.1 


1 0.3.0 


2011-08 














Editorial correction in section 7.10 because of 
misimplentation of CT#51 agreed CR 04- 
1 1 0990 


10.3.0 


10.3.1 


201 1-09 


CT#53 


CP-1 10721 




0969 


1 


A 


Additional MM context for SRVCC 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10557 


04-1 12158 


0977 




A 


Condition for sending Cause IE with DBReq 
during a HO from 3GPP to non-3GPP 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10557 


04-112160 


0986 




A 


Essential Clarification for SGSN pool 


10.3.1 


10.4.0 


201 1-09 


CT#53 


CP-1 10557 


04-1 12162 


0994 




A 


FQQontisil r'nrror'tinn tn hanrllinn nf PPnM 

session for UlOOIess UE 


10.3.1 


1 0.4.0 


2011-09 


CT#53 


CP-1 10557 


04-112169 


0996 




A 


Correction to ULI and UOI IE inclusion 
condition in Change Notification Req 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10557 


04-112191 


1000 




A 


Correction to header TEID of Suspend 
Notification over S3/S1 6 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10557 


04-112195 


1002 




A 


Extended IE handling when received fields are 
less than expected fields 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10557 


04-112199 


1016 




A 


Cause Code for DDN 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10574 


C4-1 12225 


0975 


3 


F 


MDT configuration information 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10567 


04-111754 


0980 




F 


Correction to Create Session Response LDN 
lEs 


10.3.1 


10.4.0 
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Date 


TSG# 


TSG Doc 


CT4 Doc 


CR 


Rev 


Cat 


Subject/Cc^^^^^^^^B 


Old 


New 


2011-09 


CT#53 


CP-1 10567 


C4-1 12204 


0982 


2 


F 


IP address parameter 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10567 


04-112136 


0967 


1 


F 


Signalling path failure handling 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10567 


C4-1 12145 


0983 


1 


F 


Node Type 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10567 


C4-1 12146 


0987 


1 


F 


Clarification for Context Not Found 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10567 


C4-1 12147 


0988 


1 


F 


Recovery IE in MBMS Session Stop Response 
message 


10.3.1 


10.4.0 


2011-09 


CT#53 












Removal of PCO from Failed Bearer Context 


10.3.1 


10.4.0 






CP-1 10567 


C4-111839 


1001 




F 


of Delete Bearer Request 








2011-09 


CT#53 


CP-1 10567 


C4-111906 


1006 




F 


Downlinl< Data Notification for S4 


10.3.1 


10.4.0 


2011-09 


CT#53 


CP-1 10557 


C4-1 12193 


1010 


1 


F 


MEI in Modify Bearer Request 


10.3.1 


10.4.0 


201 1-09 


CT#53 


CP-1 10577 


C4-112130 


0972 


1 


F 


01 flag in Delete Session Request 


10.4.0 
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